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PREFACE 



The growing interest in producing quality software has fostered many 
schools of thought and many alternative methods of accomplishing this 
goal. Control Data Corporation, National Cash Register Company, and 
the Advanced Systems Laboratory have chosen the programming language 
SWL (Software Writer T s Language) as a vehicle for producing quality 
software. 



This text explains ISWL (Interim Software Writers Language) in 
a tutorial manner. It is not a reference document. Where 
possible, the reasoning behind certain language features is 
examined and explained. SWL will be available in the near 
future and this document will be upgraded at that time to reflect 
the added features available to the software writer. 



Much of the material in this text comes from the questions posed in the 
many SWL classes which have been taught to-date. Certain portions of 
this material have been influenced greatly by a few individuals. John 
Sutherland provided much of the coding and ideas behind n Structured 
Programming and SWL" as contained in Chapter 5. John Dirnber g er put 
together the extensive ^ibliogra p hy" which g£ ggg£g^ in Appendix P.. 
M^T"SeggTe provided the initial impetus for producing the "CHARACTER 
COPES" in Appendix G. In addition I would like to thank the many 
colleagues who advised, discussed, suggested, and influenced the writing 
of this material. 



Ron Rothstein 
TORONTO, CANAPA 
APRIL, 1975 

Your comments on this document will be appreciated. Please address all 
correspondence to: 



Purveyor of the ISWL 

Training Guide 
Canadian Pevelopment Pivision 
Control Pata Canada Limited 
1855 Minnesota Court 
Streetsville, Mississauga 
Ontario, Canada L5N 1K7 
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INTRODUCTION 



The Advanced Systems Laboratory (ASL) was founded in September, 1973 as a 
joint venture of Control Data Corporation (CDC) and the National Cash Register 
Company (NCR). The goal of ASL is "... to design a line of architecturally 
compatible computer jsxstem^ 

both companies""to meet their respective customers 1 needs" • This new computer 
line has been christened IPL ( Int e gr a t e d Jgro duct v Line ) *• 

The method chosen to insure compatibility consists of a high-level implement- 
ation language common to all processors in the product line. This language 
is known as The Software Writer ! s Language (SWL). Product set members (i.e. 
FORTRAN, COBOL, Operating System, etc.) for the IPL machines will be written 
in SWL. In this way, a software product (such as FORTRAN) will be written 
once in SWL for all IPL machines. 

In addition, concern has been expressed regarding the quality, reliability, 
maintainability, etcetera of software. SWL will provide an effective vehicle 
for writing software in a uniform, structured manner. This will certainly 
enhance the quality of IPL software and the ability to maintain and modify 
that software. 

This text is intended to be tutorial. It is expected that the 
reader have some basic understanding of computer programming. From this 
base the text provides the building blocks for helping the reader become a 
competent SWL programmer. You will be exposed first to the concepts under- 
lying this language (i.e. What is?... block structure, pointers, procedures, 
recursion, stacks, etc.). Next, we concentrate on writing simple SWL programs, 
Then, a complete discussion of SWL data structures and the more advanced 
language constructs are presented. Finally, to improve your ability to 
program the text includes chapters on writing structured programs, applying 
IPL conventions and programming techniques, and measuring and predicting SWL 
program performance. 

This text may be read from ,r cover to cover". It is not a reference manual 
and care has been taken to provide continuity between chapters. Some of 
the chapters are used in conjunction with SWL courses and may be read 
separately. 



CDC MEMO: "FORMATION OF ADVANCED SYSTEMS LABORATORY" 
R. M. PRICE, PRESIDENT 

CONTROL DATA SYSTEMS & SERVICES COMPANY 
23 AUGUST 1973. 
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CHAPTER 1 



CONCEPTS OF THE SOFTWARE WRITERS LANGUAGE 



This chapter will explain the most important concepts of SWL. SWL syntax 
is not included. Check the list of topics below. If you are familiar with 
all the concepts listed - skip this chapter. 



CONCEPTS DISCUSSED IN THIS CHAPTER 

- Compilation Unit 

Block Structure 

Scope of Identifiers 

Procedure 

Block 

Procedures and Functions 

Calling Mechanisms 

Shielding and Sharing Variables 

Parameter Passing 

Recursion 

Pointers 

Storage Management 

Stack 

Sequence 

Heap 

- Type 
Variables 

Scope 

Automatic /Static 

Synchronous /Asynchronous Processing 

- Understanding Backus - Naur Form (BNF) 
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THE COMPILATION UNIT 

To compile any SWL program(s) the compilation unit must be defined. This 
unit (of compilation) is called a MODULE. The module declaration may 
(optionally) contain the name or identifier of the module. This module 
name becomes a most convenient way of referring to the program. The end of 
the compilation unit must also be defined. A pictorial representation of a 
compilation unit is given in figure 1.1. Remember, one and only one compil- 
ation unit can be compiled at one time. The compilation process transforms 
a single compilation unit (of source statements) into a single OBJECT MODULE, 
The compilation process is depicted in Figure 1.2. If five compilation 
units are to be transformed into five object modules, then five compilation 
processes must be used. 

Note that the compilation unit and module are not synonymous. A module 

may be used in many ways which will be covered later. One use of the module 

is to define a compilation unit. 



Module 
named 
Test Cases 



Source 
Pro- 
gram 



Module Test_Cases ; 



Modend Test Cases ; 




Compilation 
Unit 



THE COMPILATION UNIT - FIGURE 1.1 



Compilation 
Unit 



SWL Compiler 



Object Module 



THE COMPILATION PROCESS - FIGURE 1.2 
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BLOCK STRUCTURE 

A programming Language is said to be "block structured" when we can 
identify and create unique blocks (or. groups) of source statements and 
when we can associate a lifetime with the declarations in a block. A 
block (and hence block structure) in SWL can be identified in one of two 
ways: 1) BEGIN-END BLOCKS, and 2) PROC-PROCEND BLOCKS. 

The BEGIN-END Block is simply a list of source statements surrounded by 
BEGIN and END. See figure 1.3 below. 



Start 

Execution 

Here 



BEGIN 



END; 



This is the BEGIN-END 
block. It contains 
source statements. 



BEGIN-END BLOCK - FIGURE 1.3 



Of course, a given block may contain other blocks as shown in figure 1.4. 
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> 




Execution 
Here 


BEGIN 












BEGIN 












BEGIN 












END; 








END; 








END; 






^ 


BEGIN 











1 



This is the outer 
most block. It 
contains source 
statements and two 
other blocks. 



END; 



NESTED BEGIN -END BLOCKS - FIGURE 1.4 



You will notice that BEGIN-END Blocks are executed as they are encount- 
ered. In the absence of control statements the program will execute from 
top to bottom. Of what significance is all this structure? The Block 
structure enables us to easily identify the structure of the program, 
example, a block may be written that reads input data, or defines what 
execution takes place when variables A and B are equal. Implicit here 
the notion that a block may be easily replaced by another block whose 
function is similar but is improved in some way. This concept of 
"Replaceable blocks" is illustrated in figure 1.5. 



For 



is 
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BLOCK STRUCTURE - FIGURE 1.5 



Here we see (in figure 1.5) that we can have blocks within blocks. 
The BEGIN-END statements are the SWL way for implementing this block 
structure. Also note the help that this block structure provides in 
implementing software. We can write our software at an overview level 
first and then go back and amplify the details of each "block". 

Also note in Figure 1.5 that during execution only certain blocks will 
be used. For example: if the boolean test is False only one relatively 
small block is used. It would be nice if our programming language could 
utilize this knowledge of BLOCKS to reduce the amount of storage required 
at execution time, for example. In SWL, variables are declared with the 
VAR statement. Our BEGIN-END block then can take the form shown in 
Figure 1.6. 
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Start 

Execution 

Here 



BEGIN 

VAR A,B,C; 

END 



LOCAL VARIABLES - FIGURE 1.6 

In figure 1.6, the BEGIN -END block contains a declaration for local 
variables A,B, and C y as well as, some executable statements. SWL allocates 
storage space for the variables only when the block is entered. Therefore, 
if the block is not entered (as in figure 1.5) the variable won ! t actually 
be assigned storage locations and storage will be used more efficiently. 
Notice that when the block is exited, the storage locations for A, B, and 
C will become unassigned and made available for assignment to some other 
block. So at execution time, storage for variables will be created and des- 
troyed in direct relation to the requirements of the program. It is, 
however, the programmers responsibility to define blocks and variables within 
blocks correctly. 

Another feature of block structure is the SHIELDING and SHARING of variables. 
In SWL variables declared are said to be GLOBAL or LOCAL depending upon their 
position in the program and our point of reference. This problem is usually 
addressed as "SCOPE OF IDENTIFIERS". That is, we ask the question where is 
a reference to an identifier valid? What is the scope of the identifier? 
Figure 1.7, illustrates scope of identifiers. 
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BLOCK 1 



VAR A 



BLOCK 2 



VAR B 



BLOCK 3 



VAR C 



SCOPE OF IDENTIFIERS - FIGURE 1.7 



In figure 1.7 we see three blocks „ Notice that Block 1 contains Block 2 
and Block 3. Each block declares one variable (it may be an array of 1000 
integers). The declaration of variable A is local to block 1 but global 
to blocks 2 and 3. Statements within a block may make valid references to 
all variables local to their block and also to all variables global to 
their block. So, for example, statements in Block 2 can reference the 
variable A and so can statements in Block 3. 

Block 3 declares variable C to be local. Hence statements in Block 3 can 
reference variables C and A. (because A is global to block 3). However, 
there can be no reference to variable B from statements within Block 3. 
This is because the variable B is neither Local or Global to Block 3. 

In general, then, we try to declare variables in such a way as to make them 
available when needed. 

Figure 1.7, when written in SWL would appear as shown in figure 1.8. 
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Begin 




Execution 


► 




Begin 




Var A 




Begin 




Var B 




End 




Begin 




Var C 




End 


1 


i End 



Block 1 



Block 2 








Block 3 













SCOPE OF IDENTIFIERS (SWL) - FIGURE 1.8 



Of course, we could place all the variable declarations in Block 1 and 
our program would run just fine, but we might be wasting storage space 
during the program execution. 

The final question to be asked is: what happens when variable names conflict 
as in figure 1.9? 
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Block 1 


Var 


A 


Block 2 






Var A 








Block 3 






Var B 














4^ 





IDENTIFIER CONFLICTS - FIGURE 1.9 



If figure 1.9 the variable A is declared Local in blocks 1 and 2. The 
result is that any reference to variable A from within blocks 1 or 3 will 
actually refer to the A declared in Block 1. However, when Block 2 is 
entered at execution time a new (local) variable named A will be created. 
This new variable A will not destroy the old (Block 1) variable A. Of 
course, when we exit Block 2 its local variable A is removed and then 
only the A declared in Block 1 exists. 

The second method for declaring block structure is the procedure (PROC). Procedures 
are declared with the PROC-PROCEND statements as bounds on the procedure. 
Like BEGIN-END blocks, Procedure blocks may have global and local variables. 
Procedures may contain Procedure blocks and Procedure identifiers are shared 
and shielded exactly as variable identifiers are. Unlike BEGIN-END blocks, 
the Procedure block is called by referring to the name of the procedure. 

Figure 1.10 shows a simple Procedure block. 
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PROC 



XYZ; 



Procedure XYZ 



A SIMPLE PROCEDURE BLOCK - FIGURE 1.10 



Of course, procedure blocks may contain other procedure blocks as shown in 
Figure 1.11 • 



Execution of 
PROC ABC 
Begins 
here 



PROC ABC ; 

VAR X 
PROC TEST; 
VAR Y 

PROCEND TEST; 

PROC JOE; 
VAR Z 



PROCEND JOE; I 



"^ TEST; 

JOE; 
PROCEND ABC ; 



-5* CALL INVOKING TEST 
~5> CALL INVOKING JOE 



NESTED PROCEDURE BLOCKS - FIGURE 1.11 



In figure 1.11, Procedure ABC contains procedures TEST and JOE. With 
this organization TEST and JOE are SHIELDED by ABC. That is, procedures 
outside ABC may not call TEST or JOE directly. Only statements within 
ABC may call TEST or JOE. 

Any variables declared in ABC (such as X above) are global to TEST and JOE. 
Variables declared in either TEST or JOE (such as Y & Z) are local to their 
respective procedures . 

Finally, BEGIN -END Blocks may be declared within any of these procedures. 

In summary, we have examined the concept of block structure. We have seen 
how blocks may be created either through BEGIN-END or PROC-PROCEND state- 
ments. The sharing and shielding of variables was discussed in relation to 
both types of blocks. 
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Procedures 

Procedures provide two significant capabilities. First, they provide 
a mechanism by which we may isolate a number of source lines and call 
for the execution of these lines when needed. This is particularly 
helpful when we have a sequence of source lines which are repeated 
many times within the program. The procedure concept allows us to extract 
these common lines and formulate them into a Callable Unit. A call to the 
procedure then replaces the original lines of code. The call itself consists 
of the name of the procedure. 

Figure 1.12 shows a compilation unit with many common lines of code. 
Figure 1.13 shows an equivalent program when the common lines of code 
are grouped together and called Procedure A. In the body of the program 
(figure 1.13) the actual lines of code have been replaced with a reference 
to procedure named A.- When properly written, both programs produce 
identical results. During execution (figure 1.14), when the reference to 
Procedure A is encountered the statements in Procedure A are executed. 
When the end of Procedure A is reached the next Statement executed is the 
one after the call to Procedure A. 



MODULE EXAMPLE_PROCS ; MODULE; 

PROC A; 



i 



PRQGEND A; 



Common Lines A 

of Code 

A 

' A 



MODEND EXAMPLE_PROCS ; MODEND ; 

Figure 1.12 Figure 1.13 



MODULE 
PROC A ; 



PROCEND A; 



Execution 

begins here ^ 



A; 

Figure 1.14 
FLOW OF EXECUTION DURING PROCEDURE CALLS - FIGURE 1.12,1.13,1.14 
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Second, procedures provide the ability of shielding and sharing variables. 
Variables which are declared inside a procedure are called local variables, 
Their scope is the procedure (block) in which they are defined. 
See figure 1,15. 



PROC X; 
VAR XI 
VAR Yl 



PROC Y; 
VAR XI 
VAR Zl 



i 



PROCEND ; 



PROCEND X: 



executable statements 
of procedure Y 



executable statements 
of procedure X 



SHIELDING 6c SHARING VARIABLES - FIGURE 1.15 



The shielding and sharing of variables declared in procedures is very 
similar to the BLOCK method of shielding and sharing variables. In figure 
1.15 variable Yl is local to Procedure X. Since Procedure Y is contained 
in Procedure X variable Yl may also be referenced in Procedure Y . In this 
case (from the point of view of Procedure Y), we say that variable Yl is 
global to Procedure Y. Similarly, variable Zl declared in Procedure Y is 
local to Procedure Y and cannot be referenced in Procedure X. In the case 
of variable Xl^ we really have two local variables. One variable, XI 
declared in Procedure X, is local to Procedure X, The variable XI declared 
in Procedure Y, however, denotes a local variable which can be referenced 
only in Procedure Y. This is because the identifier XI appears in both 
procedures. Figure 1.16 clarifies some of these points. 



VARIABLE 


Dec 


lared 


in 


Can Variable 


IDENTIFIER 


Procedure 




be 


referenced 










in 


Procedure X? 


XI 




X 






YES 


Yl 




X 






YES 


XI 




Y 






NO 


Zl 




Y 






NO 



Can Variable 
be referenced 
in Procedure Y? 

NO 
YES 
YES 
YES 



Scope of 
the Variable 
Identifier 

Procedure X 
Procedures X 6c Y 
Procedure Y 
Procedure Y 



SCOPE OF VARIABLE IDENTIFIERS - FIGURE 1.16 
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When a procedure is called we often "pass parameters" to the procedure. 
These parameters consist of data that the called procedure needs to operate 
correctly* For example, suppose we had a procedure that: would sort arrays 
of integers. Typically, we would call the sort procedure and pass to the 
sort procedure the array of integers to be sorted. Figure 1.17 shows a 
sequence of statements. 



SORT(XARRAY); 



PARAMETER PASSING - FIGURE 1.17 

Statement "SORT (XARRAY);" calls the sort procedure and passes to it the 
values XARRAY to be sorted. Often, we pass many parameters to a procedure. 
Three mechanisms exist for making parameters available to a procedure which 
is called. These are: 1) use of Global variables; 2) passing parameters 
by "value"; and 3) passing parameters by "reference". 

The ^ Global v a^iaj^le is the simplest mechanism for paramater passing. Of course, 
Procedure TEST can re-assign (or destroy) values in the variable "X". This 
means that "X" is not very secure. It is not well shielded. It is shared. 
So Procedure TEST can pass information back to the main program through 
variable "X" or any other global variable. 

A second method of passing parameters is by value. If the parameter XARRAY, 
in figure 1.17, were passed by ya lue^ a copy of the value(s) in XARRAY would 
be made for the procedure SORT. In this way, SO RT would have access to al l 
the values of XARRAY, but would no t _ J> e,_ a b.le_t o a 1 1 e r any of the original 
XARRAY values.^ You can see that this would provide a lot offprotection for 
our original values in XARRAY. Hence, shielding or protection is excellent. 
However, communication is poor. The procedure SORT would not be able to 
return the sorted values in the original array. Some other mechanism would 
have to be used. Perhaps this would not be the best sort procedure. 

A third method of parameter pa s s i ng is b y re f ere nee . If the parameter XARRAY 
in figure 1.17 were passed by reference, a pointer to the array XARRAY would 
be. passed to the. nrocedurejSORT. This pointer would point to the original 
XARRAY. Executable statements in procedure SORT would then be able to 
reference and modify the original values in XARRAY. This is probably the 
best way for a SORT procedure. Parameters passed by reference are not 
especially secure (or protected) but enjoy the ability of providing two 
way communication. 
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The chart on figure 1.18 provides some insights into the various uses of 
the three calling mechanisms. 



PARAMETER 


PROTECTION 


COMMUNICATION 


PASSING 


(SHIELDING) 


(SHARING) 


METHOD 






GLOBAL VARIABLES 


WORST 


BEST 


CALL BY VALUE 


GOOD 


POOR 


CALL BY REFERENCE 


POOR 


GOOD 



PARAMETER PASSING MECHANISMS - FIGURE 1.18 

As you can see from the information presented in figure 1.18, no single 
parameter passing method provides the best all-round combination of 
protection and communication of variables. What we attempt to do is pick 
the right combination of protection and communication for each individual 
procedure. 

Once procedures are written, we know that they are called by simply using 
the name of the procedure as a statement (on a line). When a procedure 
calls itself we say that the procedure is being used Recursively. For 
instance, figure 1.19 shows a very simple example of recursion. 



PROC SCANNER ; 
SCANNER; <_ 



RECURSIVE 
CALL 



PROCEND SCANNER ; 



PROCEDURE 
SCANNER 



SIMPLE RECURSION - FIGURE 1.19 

We could imagine more complex examples of recursion. For example, suppose 
that a statement in Procedure A calls Procedure B and that. a statement in 
Procedure B calls Procedure A. Recursion occurs here also, but the chain of 
procedure calls is longer. This example is illustrated in figure 1.20. 
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— ? ^ 


• 



• 

B; 


CALL TO B 


• 


• 

ROCEI 


i 
TO A; 


• 
• 
• 





PROCEDURE 
A 



PROC B; f- 

i 

i 

A; CALL TO A I 

PROCEND B ; 



PROCEDURE 
B 



NOT-SO-SIMPLE RECURSION - FIGURE 1.20 

All we need say here is that these recursive calls . are lallowed. Some 
programming algorithms are expressed very concisely using recursive techniques. 
Since ISWL supports recursive procedures we can implement these recursive 
algorithms in a straightforward manner. 

Functions are a special kind of: procedure. Like procedures, functions are 
executable statements which are called from some other statement. Functions 
follow all the rules of block structure and scope of variables. Functions 
may be passed parameters exactly as procedures (global variables, call by 
value, or call by reference). 

Functions differ from procedures in two important ways. 1) the method of calling 
the function is unique, and 2) the fu act ion has a unique way (in addition 
to the conventional manner discussed for procedures) of returning values. 

A function call cannot stand as a statement by itself. The function call must 
be part of another statement. For example, consider a function to return the 
square root of its real argument as shown in figure 1.21. 



X:= 5*SQRT (Y); 



FUNCTION CALL - FIGURE 1.21 



In figure 1.21, we have an assignment statement that assigns X a 

value 5 times the square-root of Y. Of course Y must be assigned a value 

and the Function SQRT must be defined somewhere. 

What is important, however, is that the call t o SQRT_ls_jmbe ddedjLn 
statement. " "™^ " * " 



The function value (square -root of Y) is returned where the function is 
invoked. In figure 1.21, the square root of Y is returned and is then 
multiplied by 5 to obtain a result which is assigned to X. 
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POINTERS 

A pointer variable is a variable whose value represents the location of some 
other variable (or ISWL element). Pointers are used effectively to: 

1. Maintain the location of (or point to) elements in 
stacks, sequences and heaps (see page 1-19) • 

2. Point to procedures or labels. 

3. Point to user declared elements, (i.e. arrays, records, variables, etc.), 
There are, of course, other uses for pointers but these are the major uses. 

One example of using pointers is illustrated in figure 1.22. 



NIL 



VI 



V2 




VI 



V2 




NIL 



VI 



V2 



A FORWARD & BACKWARD LINKED LIST - FIGURE 1.22 



Figure 1.22 illustrates a forward and backward linked list. Each list 
element (known as a record) contains two values (VI 6c V2) and two pointers. 
The first pointer points to the next element in the linked list and is 
called the forward pointer (or forward link). The second pointer in each 
record points to the preceding record and is therefore called the backward 
pointer (or backward link). NIL is the value we give to a pointer that 
doesn ! t point to any element. 

The beginning of the LINKED LIST may be identified because it has no 
backward pointer (no record precedes it). The end of the LINKED LIST may 
be identified because it has no Forward pointer (its forward pointer is 
NIL indicating that no list element comes after this one. 

Another example of the use of pointers is a "Jump Table". The jump table 
is simply a table of pointers that usually point to procedures. 

1 
2 
3 
4 
5 



Pointer 


to 


Procedure 


XI 


Pointer 


to 


Procedure 


X2 


Pointer 


to 


Procedure 


X3 


Pointer 


to 


Procedure 


X4 


Pointer 


to 


Procedure 


X5 



JUMP TABLE - FIGURE 1.23 



Rev- B 
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Figure 1.23 illustrates the construction of a jump table. In this table 
there are five elements (or five entries in the table). Each entry is a 
pointer to some procedure. 

For instance, the table in figure 1.23 might be used to process Channel 
interrupts. If an interrupt occurs on Channel 4 we would look in the 
fourth entry in our jump table and the pointer (to Procedure X4) could 
be used to call procedure X4 to process this particular kind of interrupt. 

There are many other uses for pointers and many will emerge later in the 
text. 
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STORAGE MANAGEMENT 

When we speak of storage management we are considering stacks, sequences 
and heaps. All of these concepts involve the use of storage. Often, we 
need special methods of accessing storage. These differing methods are 
embodied in our storage management capabilities. 

Perhaps the easiest storage management scheme is the sequence. The sequence 
allows only sequential access to its member elements. A programmer will 
choose the sequence when he requires sequential access to data. 



y-{ 



THE SEQUENCE - FIGURE 1.24 



Figure 1.24 illustrates a sequence. The elements of a sequence are 
programmer defined. Each element could be an integer, a string, an array, 
a record, etc. Each sequence has a pointer associated with it. This 
pointer may be RESET to the beginning of the sequence (with a RESET 
statement). The pointer to the sequence may be advanced to the NEXT 
element in the sequence (with the NEXT statement). At any time, the 
programmer may reference the data in the sequence that the pointer points 
to. When the end of the sequence is reached (by successive applications 
of the NEXT statement), the sequence pointer becomes NIL (i.e. there are no 
more elements in the sequence). 

You can see that the access mechanism for a sequence is clearly sequential. 

The stack is simply another method of using storage. The stack is some- 
times called a push-down stack to emphasize the method of accessing data 
in the stack. The elements of a stack are accessed using the LAST IN- 
FIRST OUT METHOD . 




OUT 



THE STACK - FIGURE 1.25 
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Figure 1.25 illustrates the concept that when elements are added to the 
stack (with a PUSH statement) they are placed "on the top of the stack". 
When elements are removed from the stack (with the POP statement) they 
are removed "from the top of the stack". This then is the way the 
LAST-IN, FIRST- OUT access is implemented. Of course, a stack can be 
"emptied" with the RESET statement. 

The programmer will choose to use the stack when the FIRST IN - LAST OUT 
access method is the correct method for the problem at hand. 

The last storage management method is the Heap. 







THE HEAP - FIGURE 1.26 



Figure 1.26 illustrates that the heap does not have an explicit access 
mechanism. Elements are placed in the Heap with the ALLOCATE statement. 
Wh en _ 1 1^ ejd , a po in t e r _ ±s_ret^n^^o_j^^v±j^J^}^ 

ability to jaccess this e t lement in^THe^f uture . The programmer must save 
•^j^p"^ oite"r~~re turned. Additional elements can be placed in the Heap with 
additional ALLOCATE statements. 

When the programmer no longer needs some (previously allocated) space 
he/she may "unuse" the space with the FREE statement. l^ch FREE statement 
return^ (or makes available for future use) one element^ JunMSti^^ 
How do we know which element is FREE T d? The FKEl'^s'ta'teiment must contain a 
pointer to the element in the Heap that is to be FREE ! d. 

In summary then, the different storage management statements simply provide 
the programmer with easy-to-use methods for accessing data. These methods 
conform to the accessing methods we find most prevalent in systems 
programming. 
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TYPE 

In many programming, languages some type is associated with various elements 
such as variables. For example, it might be said that a variable is type 
"integer". In SWL a mechanism is provided to separate the definition of a 
type (e.g. , integer) from the declaration of variables. Of course, when 
variables are declared their type must be specified. But the key point is 
that the programmer may construct some type and give that type a unique 
identifier. The unique identifier, then, represents the programmer defined 
type . 

In any language there are many so-called pre-defined types. In SWL the 
pre-defined types include INTEGER, CHARACTER (abbreviated CHAR), REAL, and 
BOOLEAN. The programmer may, in addition, define additional types 
including ORDINAL, SUBRANGE, POINTER, and STRUCTURED types. 

We need not discuss all the types here. The significant concept is that 
the definition of a type may be separate from the declaration of variables. 
When a variable jls declared in terms of some type then the variable is 
restricted to values denoted by the type and in addition some referencing 
notation may be implied. 

TYPE 

TABLE = ARRAY [l..lo] OF INTEGER; 



TYPE DEFINITION - FIGURE 1.27 

In figure 1.27, TABLE is defined to be a type which is a ten element array 
of integers. The ten elements must be referenced 1 through 10. Note that 
no storage space is consumed by the type definition. The definition simply 
provides an identifier (TABLE) for a type which is an array as described 
above. 

Later in the program, if a variable is declared to be of type TABLE, that 
variable will be allocated enough storage space to contain ten integers. 
In addition, the array elements can only be accessed as elements 1 through 
10 and the contents of the array must be integers. 

It would be nice if our programming language could check (at compile time 
and execute time) that all our assignments and computations do involve similar 
types. For example, if a pointer is declared to point to a REAL it would 
be nice if the programming language could "catch" the error when we tried to 
make that pointer point to an array. SWL provides a substantial amount of 
"TYPE CHECKING" at compile time and at execute time. In simple situations 
"TYPE CHECKING" seems like a nuisance. For instance, you cannot add an 
integer to a real (directly). First you must convert the real to integer 
and add two integers (or convert the integer to real and add two reals). 
The point is that the type conversion must be explicitly written. In com- 
plicated situations, the "TYPE CHECKING" done by the compiler (and at 
execute time) saves hours of difficult and tedious debugging. 
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VARIABLES 

All variables used in a SWL program must be declared. When we declare a 
variable we specify the name or identifier of the variable, the type of 
the variable and other information such as access, storage and scope 
attributes. 

A typical variable declaration is shown in figure 1.28 

BEGIN 

BLOCK 
CONTAINING 
VAR X: INTEGER, VARIABLE 

Y: 0..15, DECLARATION 

R: REAL; 



END 



VARIABLE DECLARATION - FIGURE 1.28 



Figure 1.28 illustrates that the variable X is type integer, R is type 
real, and Y is a subrange of the integers. That is variable Y may be 
assigned only integer values in the range to 15. 

Variables declared as shown in figure 1.28 are valid (can be referenced) 
anywhere in the block in which they are declared. For a more detailed 
discussion of SCOPE of variables, see the section on Block Structure. 

In addition, variables declared as in figure 1.28 are called, " Automatic „ 
^riabl^s n . This means that storage for these variables is created (or 
made available) when the bljpcjk^i n which the variable is del!Tneci' ra Ts invoked^ 
at execution time. When (at execution time) the end of the block is 
rigltThTd^tfie^stSage space for these automatic variables is made available 
for other automatic variables. Hence, the lifetime of automatic variables 
is determined by the block containing the variable declaration. 

It is possible to create a variable which "stays around" throughout the 
execution of the entire program. These variables are called static 
yariables and their declaration is shown in figure 1.29 



BEGIN 

VAR X: [STATIC] INTEGER, 

Y: [STATIC] 0..15, 

R: [STATIC] REAL; 



END 



STATIC VARIABLE - FIGURE 1.29 
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In figure 1.29 the variables are declared to be static in addition to the 
other information which was discussed with figure 1.28. 

The STATIC attribute causes storage to be allocated once and only once 
for each variable. This storage space once allocated will not be made 
available for other variables. The result is that the STATIC variable 
has a lifetime that includes the entire program execution. 

There are other attributes for variables which will be discussed later in 
the text. 
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UNDERSTANDING BNF 

BACKUS - NAUR FORM (sometimes called BACKUS - NORMAL FORM) is used to 
describe the syntax of SWL. The syntax simply specifies VALID language 
constructs. The symantics or meaning of the language constructs are 
described in this text and in the SWL Reference Manual. Appendix B con- 
tains the BNF description of the SWL Language Syntax. 

The specification of syntactic constructs are denoted by descriptions 
enclosed in the angle brackets < and x\ These words describe the nature 
or meaning of the construct. Constructs not enclosed in angle brackets 
stand for themselves. The symbol : := is read "is defined as n and the 
vertical bar I is used to denote alternative definitions and is read "OR". 
An optional syntactic unit (zero or one occurrence) is designated by 
square brackets C and 2 • Indefinite repetition (zero or more occurrences) 
is designated by braces {* and J . 

For example, consider the sample SWL BNF below: 

< integer]? : := <digit> ^<dig±t>J 

| <digit>S"<rhex digit>V<base designator^ 

< digit> : := 1 1| 2| 3| 4|' 5J 6J 7I 8 J9 

<hex digit> ::= a|b|c|d|e|f| 
a|b|c|d|e|fl 
< digit > 

<£base designator> : := (<radix>) 

<radix> : := 2| 4 1 8| lo| 16 

EXAMPLE OF BNF - FIGURE 1.30 



In figure 1.30, we see that an <integer^ is defined as a <■ digit > followed 
zero or more occurrences of a<digit^. And, a <£digit^> is defined as 
thru 9. So a valid <integer> could be 6 or 637, etc. Also, we see the 
alternative definition of a <^digit;>is a <digit> followed by zero or more 
</ hex digit y followed by a<fbase designator^. We can see what constitues 
a valid <-hex digit> and what is a valid<base designator>. Some examples 
of valid and invalid integer follow. 



INTEGERS 




VALID 


INVALID 


7 

673 

16215(10) 

415(8) 

10110(2) 

0AEF(16) 


FFF(16) 
142(5) 



BNF INTEGERS - FIGURE 1.31 



The valid integers do not require an explanation. The invalid integers 
are described below. FFF(16) is an invalid integer because according to 
the BNF an integer must begin with a digit and a digit is defined as to 
9. The proper way to write this value then would be 0FFF(16). The integer 
142(5) is invalid because the radix (or base) of five is not allowed. 

^ccor^gJ^_the BNF the only If we 

really wanted to represent 142 Base 5, we could figure out its equivalent 
value in one of the correct Bases. For instance, 142(5) = 2F(l6) = 47(10) 
= 57(8) = 233(4) = 101111.(2). So we could use any of the valid represent- 
ations shown above for this value. 
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CHAPTER 2 
ELEMENTARY SWL 



This chapter is a tutorial on the more elementary SWL language elements. 
Emphasis is placed on learning how to write simple SWL programs. Many 
examples are provided to clarify the material presented. 

The following language elements are covered: basic constructs, symbols, 
identifiers, constants, variables, types (integer, real, character, boolean, 
subrange), declaration statements (MODULE, MODEND, VAR, CONST), assignment 
statements, structured statements (IF, LOOP, WHILE, REPEAT, FOR, CASE), 
control statements (EXIT), elementary input/output (READ and WRITE), and 
PROC [XDCLj MAIN;. 
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In every language, the programmer is faced with the probem of learning the 
symbols and keywords of the language, as well as, the rules for forming 
identifiers. 

SWL provides a number of keywords which may be used only in special 
contexts. The programmer may construct identifiers for his/her use 
but programmer declared identifiers may not be the same as keywords. 
A list of keywords (or reserved words) is given in Appendix A. 

Identifiers may be declared by the programmers • Identifiers are names 
containing 31 characters or less and begin with an alphabetic character. 
Upper and lower case letters are considered to be identical. Hence, an 
identifier written entirely in upper case letters is the same as the identifier 
written entirely in lower case letters. The valid characters after the 
first character (which must be alphabetic A to Z or a to z) include: the 
digits to 9, the letters A to Z, the letters a to z, the underscore, 
the pound (or number) sign, the dollar sign, and the at sign. 

Some examples of valid and invalid identifiers are shown in figure 2.1 



VALID INVALID 

XYZ $VAR_X 

WHEAT PRODUCTION SIX+SEVEN 



A&10 @loc 

Syntax .Table 4P3S7 

SyStEm#VaLuE _PETE_ 

FUNNY@VARIABLE D • 1 5 

X#J@ I/0 

name_f ield 
X3P7S4 
Joe 



IDENTIFIERS - FIGURE 2.1 



Now that we have the basics of identifiers and we have referred to Appendix 
A and seen the list of keywords, lets put together the skeleton of a SWL 
program. 
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Every SWL program must be bounded by the MODULE and MODEND statements, 



ACCEPTABLE 



PREFERRED 



MODULE; 



MODEND; 



MODULE INTRODUCTION; 



MODEND INTRODUCTION; 



MODULE & MODEND STATEMENTS - FIGURE 2.2 



Figure 2,2 illustrates the beginning and end respectively of a SWL program. 
In the acceptable example, we have used the minimum information necessary 
(MODULE & MODEND) to describe a SWL program. The preferred approach shows 
the use of an optional identifier (in this case the identifier INTRODUCTION) 
to provide a name for the program (or module). It is generally considered 
good programming practice to give names to modules as these names enhance 
the readability of the source text. In the preferred approach then, we 
would say that the module is named (or called) "INTRODUCTION 11 . 

You will also notice the semi-colon (;) which is included in the example. 
In SWL, the semi-colon is used as a statement separator. A semi-colon is 
needed to separate one statement from another. There are places where a 
semi-colon may be omitted. In general, when a statement is followed by a 
keyword the semi-colon is not needed. Exi:ra semi-colons may in general 
be used and will indicate an empty statement. Since the SWL compiler will 
ignore empty statements, extra semi-colons will not have any direct effect 
on the source program (i.e., they will not create errors). In some cases, 
the judicious use of semi-colons can make program modification easier, 
as will be shown later. 

When writing source lines, one is apt to ask, ,! where can blanks go? ,f . 
Generally, identifiers, reserved words, and constants must not: contain 
imbedded blanks and must be separated, one from another by at least one 
blank. 

Comments are added to the source text to enhance program clarity and may 
be used anywhere blanks can be used. The comment is enclosed in double 
quotes (")• 

The comment itself may not contain a semi-colon -Cit looks like 
a statement separator to the compilerJi a double quote -Cit* looks 
like another comment>i or a dollar sign -Cit is used to indicate 
a compile time option as described on page M-ES3-. 
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MODULE COMMENT_ILLUSTRATION; 
"THIS MODULE ILLUSTRATES THE 
USE OF THE CCMMENT TO ENHANCE 
PROGRAM CLARITY " 



MODEND COMMENT ILLUSTRATION; 



COMMENTS - FIGURE 2.3 



In figure 2.3 the use of comments to enhance program clarity is illustrated. 
Figure 2.3 contains one three-line comment. It could have been written with 
three one-line comments. 

All executable statements in SWL must be contained inside a procedure. We 
can cause the statements to be executed by calling the procedure. But what 
of the first procedure? How do we get thai: first procedure called? This 
is accomplished by the loader. After completion of the load, the loader 
simply calls the user procedure called MAIN. Since an external call is 
involved the procedure MAIN must be declared for external use. This is done 
with the XDCL (DeCLared external) attribute. 

So if we had some executable statements to perfor.n (as any real program does) 
our Module (program) would look like the one shown in figure 2.4. 

MODULE PROGRAM STRUCTURE; 



PROC [XDCL] MAIN; 

"EXECUTABLE STATEMENTS" 
"ARE PLACED HERE " 
PROCEND MAIN ; 

MODEND PROGRAM__STRUCTURE; 



PROGRAM STRUCTURE - FIGURE 2.4 



Notice in figure 2.4 above the procedure MAIN. The beginning of the 
procedure is denoted by "PROC [XDCL] MAIN;" . PROC is a reserved word used 
to introduce a procedure. QCDCL]] is used to indicate that the procedure is 
declared here and will be available for use by other external procedures 
(in this case the loader). MAIN is the name of the procedure. Of course, 
procedures can be given other names, but remember that the loader always 
transfers to the procedure named MAIN. Th<> end of the procedure MAIN is 
indicated by the statement "PROCEND MAIN •" . 
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The statements PROC to PROCEND define a procedure block. Inside this block 
we may have declarations for variables and executable statements. These 
variables and executable statements will follow the block-structuring i-ules 
discussed in Chapter 1. 

Now lets go further and introduce some variables into our program. Variables 
are declared with the VAR statement. In the VAR statement, we provide 
(minimally) the name or identifier of the variable and the type of the 
variable • There is additional information that we can specify which we 
will discuss later. The simple variable declaration then, might appear 
as : 

VAR X: INTEGER; 

In this statement VAR indicates that we are declaring a variable and also 
introduces (or begins) the VAR statement. X is the identifier or name of 
the variable and INTEGER is the type of the variable. Notice the syntax. 
A colon is used to separate the variable identifier from the type. Since we 
have said no more, variable X is an automatic variable. That is, storage 
space for X will be allocated when the block in which the VAR statement 
appears is watered (at execute time). Since X is type integer, the per- 
missable values that X may contain are restricted to the integers. 

Often in a program we need many variables. The following statements 
illustrate how this may be done: 

VAR X: INTEGER; 

VAR Y: REAL; 

VAR Z: BOOLEAN; 

VAR A: BOOLEAN; 

VAR C: CHAR; 

Notice that we have declared five automatic variables: X, Y, Z, A, and C. 
Notice the use of five separate VAR statements. The semi-colon is used to 
separate the statements one from another. Variable Y is type REAL. That 
is, Y may be assigned any real value* Variable Z is declared to be type 
BOOLEAN. Variable Z, therefore, may contain one of the BOOLEAN values TRUE 
or FALSE. Variable C is type CHARacter. Notice that we do not spell out 
the word character. We use instead the abbreviation CHAR. Variable C, 
then, may contain only a single character. 

It seems like a waste of space to have to declare VAR five times, once for 
each variable. Wouldn f t it be nice if we could use only a single VAR state- 
ment and declare lots of variables? Well, we can. Look below: 

VAR X: INTEGER, 

Y: REAL, 

Z: BOOLEAN, 

A: BOOLEAN, 

C: CHAR- 
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Notice the interesting syntax here. VAR introduces the variable declarations. 
The semi-colon separates this statement from any following statements. Note 
that all five variables are declared in ONE statement. See the use of commas 
to separate one part of the variable declaration from another. This is a 
compound statement - but it is only one statement NOT five. 

Now look at the variables Z and A above. They are both BOOLEAN. What a 
waste - having to write BOOLEAN twice. Can this be improved upon? Yes 
indeed: 

VAR X: INTEGER, 

Y: REAL, 

Z,A: BOOLEAN, 

C: CtfAR; 

In the statement above, when more thati one identifier appears on the left of 
the colon (as in Z,A) the identifiers are separated, one from another, by a 
comma and they become the type declared to the right of the colon. In 
the example above, both Z and A are BOOLEAN. 

How could we improve on this? Well, consider the prob lem of adding a variable 
to this declaration at the end (after C:CHAR;). What needs to be done? 
First we must change the semi-colon to a comma. Second we must add another 
line at the end. Two distinct lines must be changed. Similarly, if you 
consider adding a variable at the beginning of the VAR statement two lines 
must be altered. Would^t it be nice if we could add lines at the beginning 
or end and only have to make one change, the addition of the line? The 
following example Illustrates the syntax necessary to make this possible; 

VAR 

X: INTEGER, 

Y: REAL, 

Z,A: BOOLEAN, 

C: CHAR. 



We still have one statement^ but now we can simply add new lines to this 
statement with the minimum amount of effort. This is just a technique. 
Unfortunatelyn this technique will not work in the current 
version of ISUL. The technique is mentioned here to increase 
your anticipation of future versions of ISUL- 
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Notf we come to placing variable declarations in our Module. Figure 2.5 
illustrates two alternatives: 



ALTERNATIVE 1 



ALTERNATIVE 2 



MODULE VARIABLE SI;, 
VAR X: INTEGER; 

PROC [XDCLI MAIN; 
"PROGRAM BODY" 
PROCEND MAIN; 

MODEND VARIABLES 1 ; 



MODULE VARIABLES2; 

PROC [XDCL^MAIN; 
VAR X: INTEGER; 
"PROGRAM BODY" 
PROCEND MAIN; 

MODEND VARIABLES2; 



SCOPE OF VARIABLES - FIGURE 2 5 



Alternative 1 in figure 2.5 has the variable declaration inside the Module 
but outside any procedures (like MAIN). In this case, X is a global variable. 
Its scope (see Chapter 1) is the entire Module. Every procedure inside the 
Module (like MAIN) can make references to or alter the contents of variable X. 

Alternative 2 in figure 2.5 illustrates placing the variable declaration inside 
a procedure (in this example, MAIN). With this approach, variable X is local to 
procedure (or block) MAINo Variable X can be referenced or altered by any 
statement within procedure MAIN. However, if there were other procedures in 
this Module the other procedures would not have access to variable X (unless 
X was passed as a parameter to the procedure). 

Generally, we place variable declarations in the block in which they are 
needed. This "shields" the variables from unintentional alteration by 
other procedures and makes for the most efficient allocation of storage for 
automatic variables. 

Sometimes, when we declare a variable we don't want the variable to be able 
to take on all possible values normally associated with its type. For 
example, a variable declared as integer can take on all positive and negative 
integer values. It would be nice if we could restrict the values of some 
variable to the subrange to 100 for instance. This can be accomplished 
with the use of "subrange". For example, 

VAR INDEX : 0..100; 

declares variable INDEX to be type "Subrange of INTEGER", We know the 
type is a subrange because of the use of "«." to indicate lower and upper 
bounds on the subrange. The type is subrange of integer because both and 
100 are integers. With this declaration the variable INDEX can be assigned 
(or take on) only integer values from to 100 inclusive. Any other value 
placed into INDEX would be an error. We might also note that subranges are 
always expressed in ascending order (i.e. 100.. is an illegal subrange). 
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Another example can be shown with the type character (CHAR), If a variable 
is declared to be type CHAR, then, it may contain any one of the 256 ASCII 
characters. But what if we really want a variable to be able to take on 
values equivalent to the alphabetic characters 'A f to ! Z ! . Notice that 
characters are enclosed in single quotes (')„ This is to distinguish the 
character ! A ! from the variable identifier A* The following example shows 
the use of subrange of type character . 

VAR ALPHA : »A ! ..tZ ! ; 

In this example, the variable identifier ALPHA is a subrange of the 
characters. Since the lower bound ( T A ! ) of the subrange is a character, 
we can see that ALPHA will be a subrange of characters. 

Is it possible to have a subrange of the type BOOLEAN? Type BOOLEAN only 
has two values FALSE and TRUE. So a subrange here would not provide us 
with any additional capabilities even though we could define such a sub- 
range (i.e.,VAR YESJSIO : FALSE. .TRUE; ) . 

What about subranges of the REAL type? Real values are written with an 
integer part, a decimal point and a fractional part (i.e., 1.0 is a real 
number). Also, the exponential form of real numbers is allowed (i.e., 
1.3E6, represents 1.3x10 or the value 1300000). Can we have subranges 
of these real values? Would it make sense to have a subrange 1.5.. 1.6? 
You might argue that this is alright, simply restricting a real variable 
to some specific subrange. InlSWL, however, subranges of the REAL type are 
not allowed. . -~— ■ - ~_ ^ 

What about the problem of numbers to bases other than base 10? In SWL the 
bases (or radix) 2, 4, 8, 10, and 16 are allowed. So, for example, to 
represent some binary subrange the programmer might write 

VAR BINVAL : 0000(2) .. 1111(2) ; 

to represent a variable whose binary values could be from 4 bits of zero 
to 4 bits all ones. Of course there are alternative ways of writing the 
same variable, as shown in figure 2.6. 

VAR 

BINVAL1: 0000(2) . .1111(2) , 

BINVAL2: 0(4).. 33 (4), 

BINVAL3: 0(8).. 17(8), 

BINVAL4: 0..15, 

BINVAL5: 0..0F(16); 



SUBRANGES WITH RADIX - FIGURE 2.6 

All the variables in figure 2.6 are automatic variables and they all have 
equivalent subranges. We have simply shown alternative ways of writing the 
subrange 0..15 (in •i->cimal). 



Rev* B 9 c 

Z, — i. 



Occasional^ we need a constant in a program. It would be nice if we could 
give the constant a name (or identifier) and use the name instead of a con- 
stant. In addition, if the constant were needed in lots of places in the 
program we could use the identifier instead of writing the constant over 
and over again. This would have some added benefit if we had to change the 
constant at a later date. We could simply change the definition of the 
constant identifier in one place. All the references to the constant 
identifier would remain unchanged. Still another advantage is provided by 
the SWL compiler. Whenja constant is j]£QJLarji4jiL^ 

cgjista.nt» That is the constant cannot be changed by the executing program. 
Constants are declared with the CONST statement. 

Just like VAR statement, the user can write a single CONST statement which 
declares many constants or many CONST statements each declaring constants. 
As an example, suppose that we have some lower and upper bounds for subranges, 
These could be declared as constants as shown below: 

CONST 
LOWERBOUND = 0, 
UPPERBOUND = 100(16); 

In this example notice the use of the equal sign (=) . The equal sign is 
used in the CONST statement to imply an equality between the identifier 
on the left and the value on the right. 

Naturally, we can declare INTEGER, REAL, CHAR and BOOLEAN constants. The 
example in figure 2.7 illustrates the use of constants. 

MODULE CONST_EXAMPLE ; 
CONST 
LOWERBOUND = 0, 
UPPERBOUND = 100(16), 
CHARLIMIT = T Z ! , 
, REALCONST = -1 .635, 

YES = TRUE; 

PROC [XDCLJ MAIN; 
VAR 

INDEX : LOWERBOUND.. UPPERBOUND, 

ALPHA : T A ! ., CHARLIMIT, 

RANGE : -100. .LOWERBOUND* 

"PROGRAM BODY" 
PROCENI) MAIN; 

MODEND CONST_EXAMPLE; 



CONSTANT DECLARATIONS - FIGURE 2.7 



In figure 2.7 we can see the use of constants in variable declarations. 

Of course, constants may be used in other executable statements too. 

However, we have not covered any executable statements yet. 

Rev. B 2 " 9 



IN PUT /OUTPUT 

For elementary Input and Output ISWL (not SWL) provides two statements: 
READ and WRITE* These statements are really procedure calls that cause 
reading of information from (or writing information to) a file* The READ 
and WRITE statements normally use the Input and Output files, respective ly. 
However, we can alter this by parameters (on the control cards) to READ 
from (or write to) any arbitrary file. 

What kinds of data can be read? The READ procedure is capable of reading 
integers, reals and characters. The WRITE procedure allows writing of 
integers, reals, characters, booleans and strings. 

For example, the statements 

VAR X: INTEGER; 
READ(X); 

declare an integer X and then read an integer f-om the input file. The 
next integer on the file then becomes the value of X. When reading integers 
from a file, end *.of -lines on the file are treated as blanks. Blanks are 
used to separate one integer from another. Each READ statement causes the 
next integer to be read from the file. Note that each read statement does 
not cause a new line to be read. Each read statement reads the next integer 
from the file. 

In the following sequence 

VAR CH: CHAR; 
READ(CH); 

CH is declared to be type character. The read statment READ(CH) then reads 
the next character from the file. 

In the case of reading characters, the end-of-line character is not treated 
as a blank. It is read as an end-of-line character. This enables us to 
distinguish one line from another. 

A read statement may have many parameters as shown in the example below: 

VAR 

X: REAL, 

C: CHAR, 

Z: INTEGER; 

READ (X,Z,C); 

The READ statement first reads a real number from the file. Then the next 
value on the file (which must be an integer) is read. Finally, the character 
following the integer is read. 

The WRITE statement enables us to write information on the output file. The 
variables in the WRITE statement are added to the file in the order of their 
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appearance in the statement. Characters are written to the f ile in,, 
o ne ch arac t e r po s i t i on. Inte gers are written to th e file in ID 
character positions- Reals are written in SD character positions . 

We can write end-of -lines on the file (to create new lines) by writing the 
constant EOL. For example, the statement 

VAR I,J,K,L: INTEGER; 

a 

WRITE (I,J,EOL,K,L,EOL); 

writes the value of I (right justified, blank fill) in 10 character 

positions on the output file followed by the value of J, Next, an EOL 

is written on the file followed by the value of K and L. The EOL will 

cause the values of K and L to appear on a line after the line containing 
I and J. 

If we do not want the standard 10 character positions assigned to each 
real or integer written, we can specify the number of character positions 
to be used* For example, in the statement 

VAR I : 0..20; 

WRITE (1:5, EOL) 5 

!, I n is a subrange of the integers. "I n can never be less than or greater 
than 20. The write statement specifies that the value of I (whatever it 
is) will be written on the output file using only 5 character positions. 
After the value of I, an end-of -line (EOL) will be written on the file. 

For real values the WRITE statement may contain a specification like 
R:8:2. 

VAR R:REAL; 

WRITE (R:8:2,EOL); 

In this WRITE statement, R: 8:2 means write the real value R on the output 
file using 8 total character positions. The decimal portion of the real 
value R will contain 2 places. 

Since we can write strings of characters on the output file we can put 
explanatory information on the output file. This is shown below: 

VAR I : INTEGER; 

WRITE ( 'RESULT = ! , 1:8, EOL); 

The WRITE statement writes the string "RESULT = ,! on the file followed by the 
value of I (in 8 positions) followed by an end-of- line. 
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Now we can write a simple program that reads and writes data. Figure 2.8 
shows a simple program. 

MODULE INPUTJOUTPUT; 

PROC [XDCLlMAIN; 
VAR I: INTEGER; 

"READ AND WRITE AN INTEGER" 

READ(I); 

WRITE(I,EOL); 

PROC END MAIN; 
MODEND INPUT OUTPUT; 



SIMPLE INPUT/OUTPUT - FIGURE 2.8 



If we wanted to read and write two integers, we might choose either of 
the methods shown in figure 2.9. 



MODULE 101; MODULE 102; 

PROC CXDCL] MAIN; PROC [XDCL] MAIN 

VAR I, J : INTEGER; VAR I, J : INTEGER; 

READ (I, J); READ (I); READ (J); 

WRITE (I,J,E0L); WRITE (I); WRITE (j,EOL); 

PROCEND MAIN; PROCEND MAIN ; 

MODEND 101; MODEND 101; 



SIMPLE INPUT/OUTPUT (INTEGER) - FIGURE 2.9 



In figure 2.9, we have two programs obtaining exactly the same results. 
These examples show that a READ list containing a number of variables 
is equivalent to a number of READ statements each containing a single 
variable* 

Most often, however, we would like to do more than just read and write 
variables. We would like to perform some computations, make some 
assignments and write some results. So first let*s examine the assignment 
statement. 
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ASSIGNMENT 

The assignment operator in SWL is M := M • The variable to the left of the 
colon-equa,l ( :=) is assigned the value to the right oE the colon-equal. 
Of course, the types must be conforma ble. For instance, if the variable 
on the left is type real and the resulting value on the right is type 
integer the assignment is not legal. Consider the following: 



VAR X: INTEGER; 

. 

o 

x!=-3; 

Variable X is declared to be type integer. The assignment "X^-^; 11 is 
valid, because the type of the value (or constant) to the right of the 
assignment operator is the same as the type of the variable to the left 
of the assignment. 

What about operators? What operators exist and how are they used? 



OPERATORS 

SWL defines four classes of operators, these are: 

NOT OPERATOR 
MULTIPLICATIVE OPERATORS 
ADDITIVE OPERATORS 
RELATIONAL OPERATORS 



CLASSES OF OPERATORS - FIGURE 2.10 



The classes of operators are shown in figure 2*10. There is an implied 
precedence for these operators. The NOT operator has the highest precedence. 
Relational operators have the lowest precedence. Parenthesis are used to 
alter the normal order of precedence. 

The multiplicative operators include multiplication (*), division (/), 
remainder (MOD), and logical and (AND). 

The additive operators include addition (+) , subtraction (-), inclusive 
or (OR), and exclusive or (XOR). 

The relational operators include less than (<) , greater than (>), equal 
(==) , greater than or equal 0=), less than or equal (<=), not equal (/=), 
set membership (IN) and a few other set operations. 

When using these operators, the left and right arguments must conform. For 
instance, an integer may be added to an integer. A real may not be added 
to an integer. 
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In any expression, operations are performed in the order of precedence 
described above. In the following assignment statement 



VAR I 



INTEGER; 



I:= 3*5+2; 



the order of precedence is multiplication first and then addition; the 
result is I:=17. Using parenthesis we can alter the order of precedence 
as shown below. 



VAR X: REAL; 



X:= 3. 0*(5. 04-2.0); 



Here multiplication should be done first. However, in order to do the 
multiplication the right argument "(5 •0+2.0)" must be evaluated. The 
result (7.0) is then multiplied by 3.0 giving the result X:=21.0. 

All this seems elementary, at best, until we encounter some interesting 
cases. These interesting cases can be shown using the relationals* 
Remember the relational A<B really asks a question: "is A less than B n ? 
If the answer is yes the result is the Boolean value TRUE. If not, the 
result is the Boolean value FALSE. Try the next example: 



VAR B: BOOLEAN, 
I: 0..100, 
Z: REAL; 



=3; Z:=1.6; 



B 



I<5 AND Z>1.5; 



What do you think the value of B is? It appears that if I is less than 
5 and Z is greater than 1.5 B will be true. Unfortunately, the AND 
operator has a higher precedence than the relationals. So the expression 
"5 and Z" is evaluated first which is invalid. 

To fix the problem the expression must be rewritten with parenthesis as: 
"B:= (I<5) AND (Z>1.5); ,! so here the parenthesis are needed. 
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Now we can even do some elementary computation as shown in figure 2.10< 



MODULE COMPUTE; 
PROG £XDCL] MAIN; 
VAR I: INTEGER; 
READ(I); 
I:=I*I*I; 
WRITE (I,EOL); 
PROCEND MAIN; 
MODEND CCMPUTE; 



ELEMENTARY COMPUTATION - FIGURE 2.11 



The example in figure 2.11 reads an integer (I). I is then multiplied by 
itself three times (finds I to the third power) and writes out the 
result. In an expression like I: =1*1*1; wh ere operators are of the ..__ . 
same prec edence the operations a re performed left- to-r ight • 



CONVERSION FUNCTIONS 

At this point you might ask, "what can we do if we really want bo add an 
integer to a real u ? This problem is addressed with the use of conversion 
functions. In SWL, conversion functions are constructed by preceding the 
type with a dollar sign. The argument to the conversion function then is 
placed in parenthesis. Some conversion functions are shown in figure 2.12. 



FUNCTION ARGUMENT RESULT 

$REAL INTEGER REAL 

$INTEGER REAL, CHAR INTEGER 

$CHAR INTEGER CHAR 



CONVERSION FUNCTIONS - FIGURE 2.12 



For example, if we needed to add the integer I to some real value X and 
place the result in X the following method could be used: 

VAR I: INTEGER, 
X: REAL; 

X:= X+$REAL(I); 

In this example we have converted the integer I into a real value so that 
it could be added to X„ The $CHAR function is an interesting one. 
Remember that SWL uses the 256 ASCII characters. All the characters do not 
have graphic representations. How can we refer to a character we can ! t 

write (or type or punch)? 
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The answer is we convert an integer to the corresponding character. 
For example, $CHAR (53) converts the integer 53 into the equivalent 
ASCII character. The result of $CHAR (53) is a character. Remember 
the EOL character we discussed with respect to read and write statements? 
Well, $CHAR(10) is the end-of-line character. If you are interested in 
the complete list of characters Appendix G shows the $CHAR () equivalent 
of all the characters on the Control Data 713 terminal. 

The integer conversion function can be used to convert a real into an 
integer or a character into an integer. For example, $INTEGER( f A ! ) 
is the integer equivalent of the ASCII character 'A. 1 . We might note 
in passing the identity $INTEGER ($CHAR(3)). This expression finds 
the character equivalent to the third ASCII character, and then finds the 
integer equivalent of the third ASCII character. The result is, of 
course, the integer 3. 



STRUCTURED STATEMENTS 



Structured statements are statements that are composed of other statement 
lists. The SWL statements that fall into this category are: IF, WHILE, 



LOOP, REPEAT, FOR, and CASE statements. 



IF STATEMENT 



The IF STATEMENT allows for the testing of conditions and for an alternative 
execution of statement lists. 
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IF STATEMENT FLOWCHART - FIGURE 2.13 
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Figure 2.13 illustrates the conditional test and the alternative statement 
list execution* The statement list may contain any SWL executable state- 
merit including additional IF statements. The beginning of the IF statement 
is denoted by IF and the end of the statement is denoted by IFEND. 
For instance, consider figure 2,13 



VAR Y,X: INTEGER; 

IF X<0 
THEN Y:=X*X; 

WRITE (Y,EOL); 
ELSE Y:=X/2; 

WRITE (Y,EOL); 
IFEND; 



IF STATEMENT SYNTAX - FIGURE 2.14 



In figure 2.14, the IF statement includes six lines. The one IF statement 
starts at IF and ends with the line IFEND. Notice that this statement 
includes other statements. This particular IF statement tests IF X is less 
than zero. If this is true, X<0 returns the Boolean result TRUE and the 
THEN part of the IF statement is executed. The THEN portion computes Y 
as X*X and writes the resulting value of Y followed by an end-of-line. 
The next statement executed is the one after IFEND;, 

In the event that X is not less than zero, XO is FALSE and the ELSE 
portion of the IF statement is executed. The ELSE portion computes Y as 
X divided by 2 and writes the resulting value of Y followed by end-of-line. 
The next statement executed is the one after the IFEND;. 

So you can see how the SWL syntax implements the IF statement flowchart 
shown in figure 2.13. 



Some variations on the basic IF statement are supported. One variation 
is when there is no ELSE portion. In this event, the ELSE clause may be 
left out entirely. The flowchart for this short form of the IF statement 
is shown in figure 2.15. 
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SHORT IF STATEMENT - FIGURE 2.15 
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As shown in figure 2.15, the short IF statement has only one statement LIST. 
An example of this form of the IF statement is shown in figure 2.16 below. 

VAR DEBUG: BOOLEAN; 
DEBUG := TRUE; 

. 

IF DEBUG 

THEN WRITE ('CHECKPOINT 17',E0L); 
IFEND; 

IF STATEMENT SYNTAX - FIGURE 2.16 



Figure 2.16 is the kind of IF statement that eould usefully be added to 
a program for checkout purposes. First, a BOOLEAN variable DEBUG is 
declared. If DEBUG is TRUE, the IF statement THEN -clause will be executed 
writing some checkpoint information on the output file* If DEBUG is 
FALSE, the IF statement will not cause any additional output lines to be 
generated. That is, the IF statement effectively becomes a no-operation 
statement. We say "effectively" because some execution time is required 
to determine that DEBUG is FALSE and to skip over the executable statements 
in the IF statement. Also, the IF statement requires some space in the 
generated object code even if it never writes anything on the output file. 

Sometimes we have many tests to perform in order to properly execute some 
statements. A fairly typical example is a three level test for less- than 
zero, equal -to -zero or greater- than -zero. This could be accomplished 
using nested IF statements as shown in figure 2.17. 
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NESTED IF STATEMENTS FLOWCHART - FIGURE 2.17 
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When we translate the flowchart of figure 2 « J 7 into SWL SYNTAX it becomes 
somewhat complex as shown in figure 2 ,18a 



VAR Y,X: INTEGER; 

IF X==0 
THEN Y:=X*X; 
ELSE IF X<0 

THEN Y:=X+X; 
ELSE Y:=X-2; 
IFEND 
IFEND; 

NESTED IF STATEMENT SYNTAX - FIGURE 2.18 



Since these nested IF statements can become quite complex SWL has intro- 
duced the ORIF clause which can (in many cases) simplify the complexity 
of nested IF statements. The ORIF clause provides the capability of 
performing additional tests within an IF statement without the necessity 
of creating another IF-THEN -ELSE -IFEND sequence. Figure 2.19 shows how 
the example of figure 2.1 8. can be simplified using the ORIF clause. 

VAR Y,X : INTEGER; 



IF X=0 
ORIF X<0 
ELSE 
IFEND; 



THEN Y:=X*X; 

THEN Y:=X+X; 

Y:=X-2; 



ORIF CLAUSE IN IF STATEMENT - FIGURE 2.19 



Sometimes the tests in an IF statement are really individual cases. 
For instance : 



VAR Y,X: 


0..4; 




IF X=0 


THEN Y:= X*2 


ORIF X=l 


THEN Y 


:= X+X 


ORIF X=2 


THEN Y, 


= X-2 


ORIF X=3 


THEN Y 


= X-l 


ORIF X=4 


THEN Y 


■= X/2 


IFEND 







CASES IN AN IF STATEMENT - FIGURE 2.20 

In figure 2.20,X can take on values of thru 4, inclusive. The IF 
statement tests for which value X has and executes the appropriate 
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statement LIST, But when there are a finite (and relatively small) 
number of possible cases we have another statement which more clearly 
and succinctly explains the action at execute time. This statement is 
called the CASE statement. 



CASE STATEMENT 

The CASE statement causes selection of one and only one of the constituent 
cases depending on the value of the case selector. The CASE statement can 
always be replaced by some equivalent IF statement(s). But, in many 
instances the CASE statement more clearly represents the intent of the 
programmer and hence improves program clarity. 

The flowchart of the CASE statement is shown in figure 2.19. 
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CASE STATEMENT FLOWCHART - FIGURE 2.21 

The ELSE portion of the CASE statement is optional. Let ! s take the example 
in figure 2*20 and show how it is made clearer with the usre of the CASE 
statement as in figure 2.22. 



VAR 


Y 


,X: 


0..4 


CASE 


X 


OF 




=0= 




Y: 


=X*2 


—1- 
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=X+X 
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=X-2 
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Y: 
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^=4= 




Y: 


=X/2 


CASEND 


* 





CASE STATEMENT SYNTAX - FIGURE 2.22 



The CASE statement in figure 2.22 begins with the reserved word CASE 
and ends with CASEND. This is one statement. The CASE statement is a 
structured statement, which can contain many other statements, but, it is 
still one statement. 
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In the CASE statement (in the first line "CASE X OF"), the variable X is 
called "he selector and the values between the equal signs (like =0=) 
are called the cases. On entry to the case statement, the value of the 
selector is evaluated. This selector value is then used to select (or 
pick) the appropriate case for execution. For example, in figure 2,22 if 
X had the value 3 then the statement list n Y:=X-l; M would have been 
selected for execution. Upon completion of execution of this case, the 
statement after the CASEND would be executed. 

Another example of the CASE statement in figure 2.23 shows the use of the 
CASE statement to categorize characters in a syntactic analysis. 



CONST 

ALPHA = 1, 
NUMERIC = 2, 
SPECIAL = 3, 
OTHER = 4; 



VAR CH : CHAR, 

CHTYPE : 1..4; 



CASE CH OF 






='A'.. ! Z' 


= CHTYPE 


= ALPHA; 


='0 r ..»9 T 


= CHTYPE 


= NUMERIC ; 


9 9 1 


= CHTYPE 


= SPECIAL; 


ELSE 


CHTYPE 


= OTHER; 


CASEND; 







CASE STATEMENT SYNTAX - FIGURE 2.23 



In the example in figure 2.23 the CASE statement is used to classify a 
character. Notice the use of cases containing subranges. If the character 
CH is any of the characters ! A T to T Z',then we set CHTYPE to ALPHA (which 
is the constant value 1. A similar action occurs if the character CH is a 
! T thru T 9 T . Notice the use of non-contiguous cases. (= T + ! , T - ! , T / !== ) • 
If the character CH is a plus, minus, or slash character, then CHTYPE 
becomes SPECIAL. The ELSE case is generally included as a good programming 
practice. In the event that none of the cases are selected, the ELSE case 
becomes effective. 
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Figure 2.24 illustrates the effective use of the ELSE case. 



VAR X: 


0., 


.3, 


Y: 


INTEGER; 


• 

CASE X 


OF 


=0= 


Y. 


= X*X; 


=1= 


Y 


•= X*2; 


=2= 


Y 


= X-1; 


=3= 


Y 


= X+l; 



ELSE ERROR ^ROUTINE ; 
CASEND; 



ELSE IN CASE STATEMENT - FIGURE 2.24 



In figure 2,24 we can see that variable X is declared to be a subrange 
0..3 of the integers. Certainly then, the CASE statement need only 
contain the cases =0=, =1=, = 2=, and =3~ . No other values for X are 
valid. If we could rely on this absolutely, the ELSE clause would not 
be needed. However, what happens when a memory parity error exists? 
What happens on some minor failure in the arithmetic unit of the 
computer? For these UNUSUAL conditions it is an extra safeguard to 
include the ELSE case. If X should ever erroneously obtain a value 
outside the proper subrange (0..3) and the case statement is entered the 
ELSE case would be executed calling a procedure n ERR0R_R0UTINE n . Without 
the ELSE case and if X somehow becomes out of range the program would abort 
with the error message "CASE VARIABLE OUT OF RANGE". So, the ELSE case 
provides us, in this situation, an extra measure of program reliability. 



REPETITIVE STATEMENTS 



SWL provides a number of repetitive statements. These are: REPEAT, 

WHILE, FOR and LOOP. All these statements cause a list of statements 

to be executed repetitively. In some situations, the programmer could use 

any one of these statements and the choice of which statement to use 

will be an arbitrary one. However, each of these statements provides some 

special feature or capability not found in the other statements. These 

special features will be identified in the text below. 

REPEAT STATEMENT 

The REPEAT statement controls repetitive execution of its constituent 
statement list. The special feature of the REPEAT statement is that 
(upon entering the REPEAT statement) the statement list will b e executed 
at least once. Thereafter, the boolean control expression will determine 
if additional repetitions are to be performed. The flowchart in figure 
2.23 illustrates the flow of control in a REPEAT statement. Notice that 
the REPEAT statement begins with the work "REPEAT" and ends with 
the word "UNTIL". This is different than most other statements 
that end with some form of the word "END" {e.g. UHILENDi FORENDn 
ETC • j* • 
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REPEAT 




UNTIL 



REPEAT STATEMENT FLOWCHART - FIGURE 2,25 



In the flowchart 
once. After the 
formed. If the r 
When the boolean 
finished and the 
the statement lis 



of figure 2. 25 9 notice how the statement list is performed 
statement list is performed a boolean test is per- 

sult is FALSER then the statement list is executed again, 
condition result is TRUE then the repeat statement is 
next statement after the repeat is executed. Note that 
t may contain any executable statements including 
JTHcTitional (or nested) re peat statements^ 



Be* read: "Repeat 
Again, the specia 
ment list will be 
condition. 



KeHrepeal: "Statement then can 
the statement list^nFii some condition is true". 
1 feature of this statement is that upon entry the state- 
executed once regardless of the result of the boolean 



An example of the syntax of the repeat statement is shown in figure 2.26. 



MODULE SKIP_LINE; 
PROC [XDCL] MAIN; 
VAR CH : CHAR 

9 

. 

REPEAT 
READ (CH); 
UNTIL CH=EOL; 

PROCEND MAIN ; 
MODEND SKIP_LINE; 

REPEAT STATEMENT - FIGURE 2.26 



The program in figure 2.26 will read characters from the input file 
(advancing the file pointer) until the end of line character is read. 
This effectively skips over (or goes past) the first line in the input 
file. It is assumed that at least one line is in the input file. 
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Notice that upon entering the REPEAT statement the "READ (CH); n statement 

will be executed* Then the test for end -of -line is performed. If this ( 

"READ (CH); n statement did not produce an end-of-line, then the statement 

list n (READ(CH)); n is executed again. 

What happens if the file is empty? That is, it contains only an end-of- 
file? The first read will read and set the end-of-file condition 
(no end of line is present). The conditional test (CH=EOL) will of course 
be false and the statement list (READ(CH)) will be executed again. This 
will cause an attempt to read past end-of^file and the job will terminate. 

So, it would be nice if we could test for end-of-file, as well as end of line. 
Of course, we must execute the READ statement once in order to obtain any 
file Information (end-of -line, end-of-file, or a character). The REPEAT 
statement guarantees that the READ statement will be executed once. 

END-OF-FILE 

The end-of-file condition can be tested by using the boolean result 
returning built-in function #EOF( filename) . This function can be used 
to test the status of any file. If end-of-file has been reached on the 
f ile, #EOF( filename) will be TRUE. If end-of-file has not been reached, 
then #EOF( filename) will be FALSE. 

We can now modify the example in figure 2.26 to include the end-of-file 
test also. Naturally, once end-of-file is found some additional processing 
(not shown) will be required. Figure 2.27 illustrates the new (slightly) 
modified program. 

MODULE SKIP_LINE_NEW; 

PROG [XDCL] MAIN;. 

VAR CH:CHAR; 

. 

REPEAT 

READ(CH); 

UNTIL CH=EOL OR #EOF( INPUT); 

. 

PROCEND MAIN; 

MODEND SKIP_LINE_NEW ; 

REPEAT STATEMENT SYNTAX - FIGURE 2.27 



WHILE STATEMENT 

The WHILE statement causes repetitive execution of its statement list but 
slightly differently than the repeat statement. The WHILE statement does 
the co ndition test firs t_( upon entry to the while state ment) and^then^~~"" 
executes the statement lis^qnTyZif— tJbie^.Boolean conditiorTTs TRUE. With 
flnlToxg^^ that the statement list might not be 

executed at all. 



2-24 



The flowchart in figure 2.2 8 illustrates the operation of the WHILE 
statement* 

WHILE 




WHILE STATEMENT FLOWCHART - FIGURE 2.28 



An example of the use of the WHILE statement is shown below in figure 
2.29. The idea here is to read an integer and compute the factorial 
of that integer, then terminate the program. We will restrict our input 
numbers to those that are 1) positive, including zero, and 2) less than 
100. Remember FACTORIAL is 1. 

MODULE FACTORIAL; 
PROC [XDCLl MAIN; 
VAR N,FACT : INTEGER; 

READ(N); 
FACT:=1; 

WHILE N>0 DO 
FACT:= FACT*N; 
N: = N-l; 
WHILEND; 

WRITE(N:5, FACTORIAL = ! ,FACT,E0L); 

PROCEND MAIN ; 
MODEND FACTORIAL; 



WHILE STATEMENT - FIGURE 2.29 
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In the example in figure 2.29, notice how the WHILE statement performs 
the test for N>0 prior to the execution of any of the statement list. 
If the value were read for N at the beginning of the program, FACT 
would be set to 1. Then the WHILE statement would evaluate N>0 and 
the result would be FALSE. In this event, none of the statements of the 
WHILE statement list would be executed. The WRITE statement then would 
write " FACTORIAL = 1 ,f which is, of course, the correct answer. 

After reading one value of N and computing one factorial, this program 
terminates. Letfe modify the program slightly to continue reading values 
for N and computing factorials until a number greater than 100 appears on 
the input file. Since the input file may become empty (end-of- f ile), we 
will also include appropriate tests for this condition. 

With these new features, we will have a reasonably complete and safe 
program. That is, the program will not be prone to aborting abnormally. 
See figure 2.30 below: 



v 



MODULE FACT0RIAL1; 

PROC [XDCLJ MAIN; 

VAR N,FACT : INTEGER; 

. 

READ(N); 

WHILE (N<=100) AND (NOT #E0F(INPUT)) DO 

FACT:=1; 

•WHILE N>0 DO 

FACT:=FACT*N; 

N:=N-1; 
jmiLEND ; 



WRITE (N 
READ(N) 
WHILEND 



5 , T FACTORIAL = ' ,FACT,E0L) ;' 



WRITE ('END OF J0B',E0L); 

PROCEND MAIN ; 
MODEND FACT0RIAL1; 

WHILE STATEMENT (FACTORIALS) - FIGURE 2.30 

Let's review the operation of the program in figure 2.30. The WHILE 
statements have been enclosed in brackets to illustrate where they begin 
and end, and also the nesting of the WHILE statements. Upon entry into 
the program a value of N is read. The WHILE statement then checks that 
1) N is not greater than 100 and 2) that we have not encountered an 
end-of-file. If either of these conditions is false, then no statements 
in the constituent list of the WHILE statement are executed. The next 
statement executed will be the one that writes the end of job message. 
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If N is within range and there is no end-of-f ile, then the WHILE statement 
is entered. The factorial is computed as described for the program in 
figure 2.2 9. The result is written to the output file and another N is 
read. Then control is returned to the beginning of the outermost while 
statement to check the conditions on N and end of file. 

Could repeat statements have been used in the example in figure 2.30? 
The answer is of course yes - but, you will find if you write such a program 
that extra IF statements will be needed. This is because the repeat 
statement does its testing at the end of the statement list and in this 
example we need tests performed prior to executing the constituent 
statement list. 



LOOP & EXIT STATEMENT 



The LOOP statement provides for unbounded looping. The statements inside 
a LOOP statement are executed repetitively forever. The LOOP statement 
itself provides no mechanism for termination. Conceptua lly , then we might 
use a LOOP stat ement if we were writing s ome portion of an operating 
syste m, for exam ple, which was always executingT^tfie^ actual instances of 
this type of programming is relatively rare"." So a mechanism for exiting 
(or getting out of) the LOOP statement is provided. This mechanism is 
called the EXIT statement. 



The flowchart of a LOOP statement is very simple , 
2. 31 below. 



LOOP 



It is shown in figure 



A 



STATEMENT 
LIST 



LOOPEND 



LOOP STATEMENT FLOWCHART - FIGURE 2.31 



JTh e EXIT st a tement can be used to ex it__ajav^sJ;xucJLure^ (IF .REPEAT, 
FOR, CASE, WHILE, LOOP). 



The EXIT statement comes in a number of flavors. The simplest form is 
simply EXIT. When the EXIT statement is executed, it exits the structured 
statement in which it is enclosed. For example, in figure 2.32 

IF ACB 

THEN EXIT 

ELSE A:=B*Z; 

WRITE (A,B,E0L); 
IFENDj 



EXIT STATEMENT - FIGURE 2.32 
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The IF statement in figure 2.32 contains an EXIT statement. In the event 
that A is less than B then the EXIT statement will cause control to be 
passed to the statement following the IFEND. 

The EXIT statement in this example is not really needed. If the EXIT 
statement were omitted the THEN clause would be empty and the program would 
accomplish exactly the same result. 

A more meaningful use of the EXIT statement is the following. An EXIT 
statement may contain a WHEN clause which will cause a conditional exit. 
This form of the EXIT statement is shown below: 

EXIT WHEN A<B; 

When the EXIT statement is executed and A is less than B, the EXIT statement 
will EXIT, If A is not less than B this statement becomes a no-operation. 
That is, it does not EXIT. 

Now we can show how the LOOP statement and EXIT statements can be used 
together to provide a conditional repetitive statement. The example in 
figure 2.33 illustrates a method for copying a file. 



MODULE COPY; 
PROC [XDGL] MAIN; 
VAR CHrCHAR; 

LOOP 

READ (CH); 

EXIT WHEN #EOF (INPUT); 

WRITE (CH); 

LOOPEND; 

PROCEND MAIN ; 
MODEND COPY: 



LOOP STATEMENT - FIGURE 2.33 



The program shown in figure 2.33 reads characters from the input file and 
writes them on the output file. After each character read, a test is made 
for end-of-f ile. If the end of file condition is TRUE, then the loop 
statement is exited and of course the job terminates. 



FOR STATEMENT 

Our last repetitive statement is the FOR statement. This statement uses a 
control variable to control the execution of the constituent statement list. 
Control over the number of repetitions is declared explicitly rather than 
being some boolean test as is the case in the REPEAT and WHILE statements. 
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A flowchart of the FOR statement is shown in figure 2.34 



XT 



FOR 



t 



COMPUTE 
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FOR CONTROL VAR- 
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XL 



COMPUTE 
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DO 



TRUE 



CONTROL := TEMP 



±. 



FOR STATEMENT LIST 



Al4 



FIND NEXT VALUE FOR 
CONTROL VARIABLE lr 
ASSIGN TO TEMP 



FOREND 



FOR STATEMENT FLOWCHART - FIGURE 2.34 
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Figure 2,34 illustrates the FOR statement flowchart. 

r e a 1 ly on ly va 1 i d f o r^ascaad ing FOR statement^. AscendingnFOR--st~a*tements 

are those whose control variable takes on successively higher values. 

Whenjthe__c^ 

the L j^gjsta tement is descending ,. The ISUL FOR statement can only 

increment or decrement by one - 

An example of the FOR statement syntax is provided by the example in 

figure 2.35. In this example, assume that the input file contains a number 

of integer values to be added together. The first integer on the file, 

however, indicates how many additional integers are to be added together. 

MODULE SUMS; 

PROC [XDCL| MAIN; 

VAR I,M,N,S: INTEGER ; 

S:=0; 

READ(M); 

FOR I:= 1 TOM DO 

READ(N); 

S:=S+N; 

FOREND; 

WRITE('SUM = ',S,EOL); 
PROCEND MAIN; 
MODEND SUMS; 

FOR STATEMENT SYNTAX - FIGURE 2.35 



Notice in the FOR statement in figure 2.35 that the control variable (I) 
will take on successive integers from 1 to M where M has been read from 
the input file. The FOR statement, then, is executed M times. Each time 
a new value is read it is added to the sum S, When the FOR statement is 
exhausted (after M iterations), the sum is written to the output file. 

When we wish to choose control variable values in descending order we use 
the reserved wor d DOWNT O instead of TQ. t We might also note that the 
control variable need not be integer. The control variable can be any 
type whose successor and predecessor values may be found. For J^xamgle^, ^ 
this J^puld_ inc : l_ude_ the : ^haracter^s^ 

Have you ever had trouble saying the alphabet backwards? The example 
in figure 2.36 illustrates a program to produce the alphabet backwards 
so you will have the correct sequence to practice. 
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MODULE BACK_ALPHA; 
PROC [XDCLj MAIN; 
VAR I: 'A'.^Z 1 ; 

FOR I: = »Z' DOWNTO »A ! DO 

WRITE (I,EOL); 

FOREND; 

PROCEND MAIN ; 
MODEND BACKALPHA; 

FOR STATEMENT SYNTAX - FIGURE 2.36 



In the example in figure 2,3 6 variable I is declared to be a subrange 
of the characters ( ! A ! to ! Z ! )* That is to say that at execution time 
I may take on only alphabetic characters ! A ! to ! Z ! (but not necessarily 
in that order). The FOR statement indicates that I is to take on values 
from ! Z T DOWNTO ! A» . The WRITE statement writes each successive value 
of the control variable on a line by itself on the output file. In this 
way the characters Z Y X W etc. are listed on the output file. 



REPETITIVE STATEMENT COMPARISON 

While each of the repetitive statements (FOR, WHILE, REPEAT, and LOOP) 
has some special feature associated with it, there will be many times when 
the choice may be arbitrary. 

As an example, lets look at the problem of creating some repetitive 
sequence from 1 to LIMIT. In our example, the value of the control variable 
must be available during each iteration. 

How can we solve this programming problem with each of the four repetitive 
statements? The next four figures 2.37 thru 2.40 illustrate some solutions 
to the problem. 

CONST LIMIT = 100; 

VAR I: 1.. LIMIT; 

. 

FOR I:= 1 TO LIMIT DO 



FOREND; 
REPETITIVE FOR STATEMENT - FIGURE 2.37 
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ONST LIMIT = 100.; 
AR I : 1 .<tfj5n^l\ 



I:=l; 
REPEAT 



I :=I+1 

UNTIL I ^ LIMIT} 

REPETITIVE REPEAT STATEMENT - FIGURE 2.38 



CONST LIMIT = 100; 
VAR I : 1..LBHT+1; 

I:=l« 

WHILE I<= LIMIT DO 



I:=I-tl; 
WHILEND; 

REPETITIVE WHILE STATEMENT - FIGURE 2.39 



CONST LIMIT = 100; 
VAR I : 1..LTMIT+1; 

l!=l; 
LOOP 



I: =1+1; 

EXIT WHEN I > LIMIT} 

LOOPEND; 
REPETITIVE LOOP STATEMENT - FIGURE 2.40 



You are bound to ask, 'Which of the above four methods is the best?" 
And by that question you mean 1) which method requires the least execution 
time and 2) which method requires the smallest storage requirements or 
3> which method is most easily understood and maintained? Ue 
don't know the answer yet - but we are working on it J 



Rev- B 2-32 



CHAPTER 3 
SWL DATA STRUCTURES 



This chapter presents both concepts and examples of structuring data in 
SWL. We begin with a discussion of SWL types • This includes both the 
declara tion and use of_ _types.. We progress onto type conformity and the 
use of type testing. We. will amplify the material on variables presented 
in the last chapter to include some of the more important variable 
attributes, data structures, and variable references. We will also 
discuss value constructors and variable initialization. 
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TYPES 

In the last chapter we examined some of the more primitive (or elementary) 
types including integer, real, boolean, and character. The point was made 
that a clear distinction exists between the variable and the type of the 
variable. The simple variable declaration statements like "VAR XrlNTEGER;" 
were used to declare an automatic variable X and its type-integer. Now, 
an expansion of the type specification facility is needed. 

In SWL, the capability exists to declare a type. Not a variable - just the 
type. When this is done, the reserved word TYPE is used to introduce the 
declaration. A simple example is shown in figure 3.1. 

MODULE TYPE J3ECLARATI0N ; 
TYPE Q = INTEGER^ 

. 
VAR X:Q; 

MODEND TYPEJDECLARATION; 
TYPE DECLARATION - FIGURE 3.1 



In figure 3.1 above, the reserved word TYPE is used to introduce the type 
declaration. Q is the name (or identifier) of the type. The equal sign 
is used to signify equality between the name Q and the type INTEGER. 
What has been accomplished is simply to provide an alternative identifier 
"Q r which stands for (or represents) type integer. You can see how this 
identifier can be used in the VAR statement. Instead of specifying 
"VAR X.-INTEGER;" it is possible to declare "VAR X-.Q;". Which simply says 
that X is to be type Q f but xjp^kno^tha t Q^is^type^ integer . 

So one thing an explicit type declaration allows is the ability to give 
a name to a type and use the name to stand for the type. This 
can be especially useful when the type itself i^^uiJLjaJeagJth^ (say 5 or 
more lines^a^JjaJLhe-^ase of recor2iJl — - ™__~ 

Another use for the explicit type declaration is that some SWL language 
elements make reference to type. An example is to declaration of pointers 
which must point to a type. In this case, the type declaration can be helpful. 

In the last chapter,, we examined the types integer, real, boolean, and 
character. Now we will examine some of the more complex (and useful) types. 



ORDINA LS 

Ordinals are used primarily to provide meaning and clarity to the program 
text. An ordinal is user defined and is scalar. That is the user defines 
the elements of the ordinal in some order. Once the order is declared it 
is fixed. In general, then, it is possible to determine the predecessor 
and successor for any element in the ordinal. Once ordinaj^j^n^^iers 
are declared the identifiers may not be used in any~o^EeF^ontext injthe 
^pT^^^^ThlT identifiers may be used solely toHInHicate the elements of 
the ordinal. 
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Let us assume that we have a program that processes grain production 
values ft The grains we are interested in are wheat, oats, barley, and 
rye.. We could define a type GRAIN which could be any of the four grains 
we are interested in, see figure 3.2. 

TYPE 
GRAIN = (WHEAT, OATS, BARLEY, RYE); 

ORDINAL TYPE - FIGURE 3.2 



Notice the use of parenthesis in figure 3.2. Parenthesis around t he fou r 
ident ifiers indicate t hat these are ordina l el ements . We should also note* 
that thereTexists a direct relationship between the ordinal identifier and 
its position. Wheat is the Oth ordinal element. Similarly, OATS is the 
1st ordinal element, BARLEY is the 2nd and RYE the 3rd ordinal element. 

Once an ordinal type is declared we can do lots of interesting things. 
For example, we can declare variables that may take on values of the 
ordinal as shown in figure 3.3. 

TYPE 
GRAIN = (WHEAT, OATS, BARLEY, RYE)- 

a 

VAR 

INDEX : GRAIN; 
■ . 

INDEX := WHEAT; 

ORDINALS - FIGURE 3.3 

In figure 3.3 above a variable INDEX has been declared to be t yjg e GRAIN. jwk 

That means t hat the vari able INDEX can be .assigned any of the appropriate 

"values" 6F"the ordinal as illustrated b y the "INDEX;=WHEAT ;" statement'*" 

How does all this improve program clarity? Assume that we wish to find 
the total production of grain when we know the production of wheat, oats, 
barley and rye. If the production values (4 of them) are real and exist 
on an input data file then the following program could get the task 
accomplished. 

MODULE SUMMATION; 

TYPE GRAIN = (WHEAT, OATS, BARLEY, RYE); 

PROC [XDCLj MAIN; 

VAR I : GRAIN 

V, PRODUCTION: REAL; 
PRODUCTION :=0; 
FOR I:=WHEAT TO RYE DO 
READ (V); 

PRODUCTIONS PRODUCTION +V; 
FOREND ; 

WRITE ( » PRODUCTION^ , PRODUCTION, EOL) ; 
PROCEND MAIN; 
MODEND SUMMATION; 

USE OF ORDINALS - FIGURE 3.4 

3-3 



Perhaps the most interesting aspect of the program in figure 3.4 is the 
statement "FOR I := WHEAT TO RYE DO 11 . Since WHEAT and RY E J^e jjnique_ 
identifiers (representing the Oth and 3rd e lement s of^tne^rjjLna 1 GRAIN), 
we can use them as ordil1^]r~cnon^taTii^^ — S^n^e^ThT^o^dina 1 constanlfsHSveTa 
SCALAR"" ordering (su^TCessor andHpr^decessor) the SWL compiler can generate 
code to find the successive values as required by the FOR statement. Note 
that the control variable in the FOR statement (I) must be type GRAIN in 
order to accept the values WHEAT.. RYE. Isn T t that program much clearer 
nthan one in which the FOR statement read "FOR I:= to 3 DO"? If the FOR 
j-^ statement says "0 to 3" it is not clear what is being done. If the FOR 
$ statement says "WHEAT TO RYE" it is pretty obvious that the program is 
^)F dealing with GRAIN. 

j zk< ^ s Y ou roight: imagine these ordinal values can be used in subranges (WHEAT., 

OATS) and as cases in the CASE statement. 



<>\ 



% 



It was mentioned above that the ordinal identifiers are ordered and there 
is an equivalence (of sorts) between the 0th element in the ordinal list 
and the first identifier. How then can we convert an ordinal identifier 
into an integer and an integer into an ordinal identifier? 

Figure 3.5 shows how an ordinal identifier can be converted into an 
integer using the $INTEGER conversion function. 

TYPE 
COLOR = (RED, YELLOW, BLUE, GREEN); 
VAR X: COLOR, 
I: 0..3; 



I:= $INTEGER(BLUE); 
CONVERTING ORDINALS TO INTEGERS - FIGURE 3.5 



In figure 3.5 the statement n I:=$INTEGER(BLUE) ;" converts the ordinal 
identifier BLUE into an integer (the value would be 2) and then assigns 
the value to an integer variable (I). The statement n I:=BLUE; !l would 
not be valid since the type of I is integer and BLUE is a member of an 
ordinal* Our program must, therefore, make the types equivalent by 
using the conversion function $INTEGER. 

Now let ! s go the other way, converting an integer into an ordinal element 
as shown in figure 3.6. 



TYPE 

HARDWARE = (NAILS , TACKS ? SCREWS); 
VAR 

H: HARDWARE, 

I: 0..2; 

I:=l; 

H:= $HARDWARE (I); 

CONVERTING INTEGERS TO ORDINALS - FIGURE 3.6 



In figure 3.6 the statement M H:=$HARDWARE (!);" takes the integer value 
I and converts it to type HARDWARE (in this case since I:=l, the 
conversion $HARDWARE (I) will result in the ordinal TACKS) and the 
resulting ordinal, TACKS, would be assigned to the variable H. 

It is often quite a convenience to be able to go back and forth between 
the ordinal identifiers and their equivalent integer representation. 



ARRAYS 

The array type is a convenient way of providing random access to a number 
of homogeneous elements. Arrays can have any number of dimensions (there 
is no, arbitrary limit). An array has two significant components: 1) the 
indices and 2) the contents. 



ray declaration is "ARRAY tindicesj OF type' 1 , 
of an array the indices and type of component 



The general syntax of an arra} 

That is, in the declaration of an array the indices anct type of components 

must be specified. 

Perhaps the simplest array structure is one that is one dimensional, has 
integer indices, and contains integer components. This type would be 
declared as shown in figure 3.7. 

TYPE 
TYPICAL = ARRAY {0..100J OF INTEGER; 

VAR 
X: TYPICAL; 

TYPICAL ARRAY TYPE - FIGURE 3.7 



Figure 3.7 shows an array declaration that is typical* The array contains 
101 distinct elements (0..100) and each element is an integer. The variable 
X is type TYPICAL which means that X is an array of 101 integer elements. 
In a program, the identifier X is used to refer to the entire array. To 
refer to any single element (integer) of the array the notation X[I] is used; 
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■I" can be an integer from to 100 (as defined by the TYPE declaration). 

An example of the declaration and use of arrays is shown in figure 3.8. 

^ MODULE ARRAY_SETUP; 

$ PROC [XDCL] MAIN; 

<E TYPE 

A = ARRAY [-5.. 5*] OF INTEGER; 

<> VAR 
Jj X:A, 

^ I: INTEGER; 

J FOR I:= -5 TO 5 DO 

^ X [l] := 1*5; 

% FOREND; 

? PROCEND MAIN ; 

Q MODEND ARRAY_SETUP; 

USE OF ARRAYS - FIGURE 3.8 



^? In the example in figure 3.8, the variable X is type A. Type A is an array 
^ "' of integers. There are 11 elements (or indices) for this array -5 thru+5. 
«^F The FOR statement selects successive values from -5 to+5and assigns these 
to the con trol variab le I. The array X is then initialized element by 
element. 

We may also declare arrays with more than one dimension by declaring an 
array of an array. This may be done in either of two ways illustrated in 
figure 3.9. 

TYPE 
TW0D1- ARRAY [l..l0] OF ARRAY [l..l0] OF REAL; 

TYPE 
TW0D2= ARRAY [l . .10,1. .10^ OF REAL; 

MULTI -DIMENSIONED ARRAYS - FIGURE 3.9 



Figure 3.9 shows the two ways for declaring a two dimensional array type. 
The first method is preferred as it clearly illustrates the concept of a 
two dimensional array as an array of an array* Regardless of which method 
is ussd i:o declare the array type, any variable that is a two dimensional 
array can be referenced in either of two ways, as shown in figure 3.10. 
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TYPE 

A = ARRAY |j...lO] OF ARRAY £20.. 30] OF INTEGER; 

VAR 

X:A; 



X[5,2l] := -67; 
X [8][22] := 73; 



ARRAY REFERENCES - FIGURE 3.10 



Figure 3.10 illustrates the two (equally correct) methods of referencing 

a two dimensional array. The first method M X[5,2l] n is correct but not 

preferred. !, X[8][22j M is preferred because it clearly carries thru the 

idea of double subscripting and the idea of an array of an array. We 

should also note that using the example in figure 3.10, X{j3] is a valid reference 

and refers to one array 20.. 30 of an integer. In fact each X£l] (where I is 

from 1 to 10) is an array 20 -.30 of integer. 

Some examples of array concepts and their specification is SWL are given 
be low : 



? 


TRUE 


FALSE 


TRUE 


FALSE 


FALSE 


FALSE 


TRUE 


TRUE 



TYPE 
TRUTHTABLE = ARRAY [BOOLEAN ] OF 

ARRAY [BOOLEAN} OF BOOLEAN; 



VAR 
X: TRUTHTABLE; 

X [TRUE] [TRUE] := FALSE 
X pRUEJ [VaLSu] := FALSE 
X [FALSE, TRUE] := TRUE 

A BINARY TRUTH TABLE - FIGURE 3.11 









oooooooooooo. 



1111111111112 



12 


BITS 






j~ 




* 7 
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CONST 

LIMIT = 111111111111(2); 
TYPE 

MEM = ARRAY £o., LIMIT] OF 0.. LIMIT; 
VAR 

MEMORY :MEM; 
• ■ 

MEMORY [0111(2)] := 010110101101(2); 
MEMORY D7(8)l := 0476(8); 
MEMORY [1079] := 3215; 



A 12 -BIT MEMORY WITH 12 -BIT ADDRESSING - FIGURE 3.12 



$CHAR (0) 



8 BIT 
ASCII CODE 



5 



$CHAR (255) 



5 



CONST 

MAXVALUE = 255; 
TYPE 

A=ARRAY [CHAR] OF 0.. MAXVALUE ; 

^ ( VAR ' - : \^ 

^TRANSLATE : 1"7\ 
V 3lI-2]Q l. .MAXVALUE; .) 

9 

m 

I := TRANSLATE [j Bt ]; 

I := TRANSLATE [$CHAR (26)] ; 



A CHARACTER CONVERSION TABLE ,. FIGURE 3.13 
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j SWL provides us with a couple of very powerful array operations. These are 
\? (lirray assignmerTt) and array equality testing. No other array operations are 

— -ri~~ Ii " — "~ - ~ x '""" ' * 

allowed. 

Array assignment allows the element by element assignment of one array to 
another if the arrays are the same type. This can eliminate many 
repetitive statements. Also, arrays may be compared for equality. Two 
arrays (of the same type) are equal if every pair of corresponding elements 
are equal. These operations are illustrated in figure 3.14. 

VAR 
X,Y : ARRAY [1..10] OF REAL; 

X:=Y; 

IF X=Y 

THEN WRITE ('ARRAYS EQUAL*, EOL); 

ELSE WRITE ( T ARRAYS NOT EQUAL', EOL); 
I FEND; 

ARRAY OPERATIONS - FIGURE 3.14 



STRTNGS 

The string type provides a convenient way of manipulating strings of 
characters. We could, of course, create an array of characters. But 
arrays ar,i accessed one element at a time. So an array of characters 
would always have to be accessed one character at a time. 

Sometimes what we really want to do is manipulate a number of characters 
(a string of characters) as a unit. In addition, we would like to be able 
to examine sub-str Lags of various lengths without accessing each 
individual character. 

A string may only Ciins^.t__,oL,_ charac ter s . Strin gs of other types ( such as. 
R eal. Boolean, etc.) are not allowed. Figure 3.15 shows how a string type 
declaration might appear. 

TYPE 

ONELINE. = STRING (72) OF CHAR; 

VAR X: ONELINE; 

STRING TYPE DECLARATION - FIGURE 3.15 

In figure 3.15 the type identifier is 0NE_LINE. The reserved word STRING 

declares this type to be a string. The u (72) OF CHAR" declares the length 

of the string to be 72 characters. The variable X is then declared to be 
type 0NE_LINE. 
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S TRING REFERENCING 

When the name (or identifier) of the string (X in figure 3.15) is used it 
refers to the entire string. So, X in figure 3.15 refers to a string of 
72 characters. 

An y indivi d ual char acter may be referenced by g iving the jx>si J:.ion_o f _t he 
c haracter irTlHr^^ For example X(l) is a reference 

to the first character of HEEe~~str ing . X(72) would be a reference to the 
last character in string X. 

So far 5 string referencing is identical to one dimensional array referencing 
except that the parenthesis () are used in string references and the 
square brackets £ ]are used in array references. 

But string references also include the ability to reference a sub-string 
of any valid length. This method of reference has no equivalent with 

respect to arrays. Toj^Xex ko^a^su b strin g the following, f orm is used 

^j^feaxti^ So X(l,10) would refer to the substring 

starting in position one and having a length of 10 characters. The length 
position of the reference may contain an askerisk (*) indicating that the 
length should extend to the end of the string. For example X(70«*) :ls_g„ 
sub^r^ X. We might note that there is 

some overlap of references. ¥o?~instance7x , X(l,72) and X(l,*) all refer 
to the entire string X. Similarly, X(70, 3) and X(70,*) both refer to the 
last three characters of the string X. 

Let ! s put this information to use by writing a short program which reads one 
line from the input file and builds a string. Then the program will write 
the string. Remember , j sjijiing^can^he^wxXt^^ 39 t ^- r ^ a A • 

We can, hpj^j^ji <t _r ea d chara<^ ggxsL% So, our approach is to read one character 
at a time from the input file and build the string (one character at a time). 
When the string is built, it is written to the output file. 



^ Q xv, C: CHAR; 



MODULE STRING_RUILD; 
PROC [XDCL] MAIN; 
CONST STRLEN = 80; 
VAR LINE: STRING (STRLEN) OF CHAR, 
LEN: INTEGER, 






jg/rtrtrt 



f 



LEN:=0; 

READ(C) 

WHILE (C /=E0L) AND (NOT #E0F (INPUT)) DO 

LEN:=LEN+1; 

EXIT WHEN LEN >= STRLENi 



X LINE (LEN):=C; 

WRITE (LINE(1,LEN),E0L); 

PROCEND MAIN; 
MODEND STRING_BUILD; 

BUILDING STRINGS - FIGURE 3.16 
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In the program in (figure 3.16), we assume that no line (string) will exceed 
80 characters • If a line does exceed 80 characters only the first 80 
characters will be added to the string. Since our string length has been 
declared to be 80 characters, and a line may contain fewer characters we 
need to keep some indication (LEN) of the current (or actual) string 
length. The WRITE statement then writes the substring " LINE (1, LEN)" 
containing the actual characters read fron the input file. 

Another example of the use of strings is contained in the next example (figure 
3.17). Here we have an array of strings. Each array element is a string 
of characters. The program compares a given string with all the strings in 
the array to see if the string can be found. A string constant may be 
constructed by placing a number of characters in quotes. For example, if 
S is a string then "S(l,3) := T ABC ! ; " assigns the string ! ABC r to the 
substring S(l,3). 



Before looking at the program skeleton, 
the problem conceptually. 



see figure 3.17 which illustrates 
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ARRAY OF STRINGS 



STRING SEARCHING - FIGURE 3.17 



Figure 3.17 illustrates the array of strings. Each string might be the 
name of a person, or the name of some variable, etc. The search string 
will be compared with each element (string) in the array. 

The program skeleton to accomplish this string search is shown in figure 
3.18 below. 
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MODULE S TRING_SEARCH ; 
PROC [.XDClJ MAIN; 



CONST .j^ 

SLEN = 10, d^ 

ASIZE = 100; V° 






TYPE 
STR = STRING(SLEN) OF CHAR; 

VAR 

SARRAY : ARRAY |[l..AStZE'3 OF STR, 

SSTR : STR, 

I : 1..ASIZE+1; 

"ASSUME SARRAY IS " 

"INITIALIZED BY THE PROGRAM HERE 1 ' 

"BEGIN STRING SEARCH" 
SSTR := ' SMITH, JOHN 1 ; 

I:=0; 

REPEAT 

I:=I+1; 

UNTIL (SSTR=SARRAY {Y}) OR (I>ASIZE) 

IF I^ASIZE 

THEN WRITE (SSTR, ! FOUND AT POSITION 1 ,I,EOL) ; 

ELSE WRITE (SSTR, ! NOT FOUND ; EOL) ; 
IFEND; 

PROCEND MAIN; 

MODEND STRING SEARCH; 



STRING SEARCH - FIGURE 3.18 



Another example of string searching uses the concept of sub-strings. This 
problem is to find certain keywords in a line. In SWL terminology, we want 
to find the occurance of a substring in a string. 

If we can assume that we have a line (string) of characters and a keyword 
(string), then the problem is to check each and every substring in the line 
for a matach against the keyword string. The search is shown conceptually 
in figure 3.19. 
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LINE (STRING) 




C CM PARI SONS 



\y v» 



KEYWORD (STRING) 



FINDING ONE STRING IN ANOTHER - FIGURE 3.19 



The SWL program to accomplish this search is shown in figure 3.20. 



MODULE SUB_STRING_SEARCH ; 

PROC [XDCL] MAIN; 

CONST 

LINELEN =80, 

STRLEN = 3; 

VAR LINE: STRING (LINELEN) OF CHAR, 
KEYW: STRING (STRLEN) OF CHAR, 
I : 1.. LINELEN -2; 

"ASSUME LINE IS INITIALIZED HERE' 1 

KEYW := T XOR ! ; 

"BEGIN SEARCH" 

FOR I:= 1 TO LINELEN-2 DO 

IF KEYW = LINE (1,3) 

THEN WRITE ( KEY W, T FOUND AT POSITION" , I, EOL) ; 
IFEND; 
FOREND; 
WRITE ('END OF JOB 1 , EOL); 

PROCEND MAIN ; 

MODEND SUH STRING SEARCH; 



SUB-STRING SEARCH - FIGURE 3.20 
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STRING CONVERSIO N L 

When a string is not the right length for either an assignment or a 
comparison we have the task of converting the string to the correct size. 

The $STRING conversion function accomplishes the task. This conversion 
function can be used to lengthen (by filling on the right) or shorten 
(by truncating on the right) a given string. 

For example, suppose we had defined a string in the following way : 

VAR S: STRING (80) OF CHAR; 

and we wish to initialize the string without having to write 80 blanks. 
We might use : 

S := $STRING (80, T '); 

The $STRING function says take the string ( ! ! ) and extend it to 80 
characters. Blank fill is used by default. We can specify fill 
characters as shown below 

S := $STRING (80, ! ABCD* , »** ) • 



STRING REPRESENTATION 

Another thorny problem is that of converting a value into the character 
representation of the value. For example, converting the integer 125 
into the character string T 125 ! . This task is accomplished with the 
$STRINGREP Procedure. 

The function is defined as follows: 

$STRINGREP( VALUE, SUBSTRING, WIDTH, DECIMALS) 

Where value is the integer, real, or Boolean. 

SUBSTRING is the character representation 
constructed by the Function. 



WIDTH 



is the number of character positions, 



^ DECIMALS is the number of decimal positions 
for real numbers. 

Boolean values are converted to the string 'TRUE' or ! FALSE' RIGHT - 
JUSTIFIED, blank-filled. 

Reals are represented as decimal numbers with exponent base 10 with 
"DECIMALS' 1 digits after the decimal point. 

Integer values are converted to "WIDTH "decimal digits with leading zero 
replaced by blanks. 

1 - ISWL facility only,, Automatic adjustment of string length in SWL 

will be accomplished using varying strings. 

2 - This ISWL facility will be addressed by general formatted I/O in SWL 
REV. A 
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An example is shown below: 

VAR S: STRING (10) OF CHAR, 

I: INTEGER 5 
I:=-1276; 
#STRINGREP (I,S,10); 

Notice that #STRINGREP is a procedure, 

POINTERS 

SWL has a very powerful pointer capability which is used throughout 
the language in many ways. In this section, we will present the more 
elementary and straight forward uses of pointers. The other interesting 
uses of pointers will be covered under the topics of storage management 
and records • 

In SWL, when a pointer is declared it is done with reference to a type. 

^At execution time, a pointer varijaM some specific 

^ccuranc^ at declaration the pointer is said to point 

to a type - not a variable. 

The pointer symbol A (/on some terminals) is used to make reference to 
or declare a po inter e 

Some declarations of pointer types and pointer variables are shown in 
figure 3.21. 



TYPE 
A = STRING (10) OF CHAR, 
B = ARRAY [1..10] OF INTEGER, 
C =AA; 

VAR 
APTR :AA, 
APTR1: C, 
BPTR : AB, 
INTP :A INTEGER, 
VARA : A, 
VARB : B; 

POINTER TYPES - FIGURE 3.21 

In figure 3.21, we see a number of different pointer declarations. First, C 
is declared to be a type which is a pointer to the type A (a string of 10 
characters). Of course C is not a variable, just the name of a type. 
Looking at the variable declarations we see a variable APTR which is an 
automatic variable that is a pointer to the type A. The variable APTR1 is 
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also a pointer to the type A. This is so because APTR1 is type C and C 
is type pointer to type A. BPTR is a variable that is a pointer to type 
B (an array of integers). INTP is a variable that is a pointer to any 
integer. VARA is a variable that jLs type A (a string of characters). 

At execution time , VARA will become a string of characters. Variable APTR 
(which is a pointer to a string of characters) could be made to point to 
<3j{t VARA at execution time. 

Since pointers may onl y be declared as po ir^erjQ:p_s L ome, J:,y.pe^the„ ? fol lowing 

VAR X: INTEGER, 
Y:A X; 

is an error. Notice that Y is declared to be a pointer to a variable. 
This is a no-no. Perhaps what is needed is a pointer to X at execution 
time. But at declaration time, the sequence of statements would look like: 

VAR X: INTEGER, 
Y: A INTEGER; 

Here Y is a pointer to type integer. X is a variable whose type is 
*£> integer. At execution time,Y could Joe^ad^Jtp^ppint^SLj^.. 

POINTER REFERENCES 

Once pointers have been declared it becomes necessary to be able to 
reference not only the pointer but what the pointer, points to. These 
problems of reference are also handled with the pointer symbol. 

Another problem, is what to do with an empty pointer, i.e., the pointer 
doesn T t point to anything. 

In SWL,the reserved word NIL is used to indicate an empty pointer. Any 
pointer can be set to NIL. When a pointer is tested and found to be NIL, 
then we know that it does not point to anything. 

There are four possible ways in which the A symbol may be used to 
indicate pointer references- Two of these use' the A symbol on the 
right of an assignment and two use the A on the left of an assignment. 
Consider the following: 

TYPE 
A = ARRAY [1..10] OF REAL; 

VAR 

P:AA, 
X,Y: A; 

. 

P :=AX; "P IS ASSIGNED A POINTER TO X" 

X :=PA; "X IS ASSIGNED WHAT THE POINTER P POINTS TO" 

PA:=Y; "WHAT THE POINTER P POINTS TO IS ASSIGNED Y n 

AP:=X; "THIS FORM IS ILLEGAL" 

POINTER REFERENCES - FIGURE 3.22 
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Figure 3.22 illustrates the four possible uses of the A symbol in assign- 
ment. Basically, the A symbol to the left of a variable (AX) means 
"construct a pointer to X M . The K symbol on the right of a (pointer) 
variable means !t use what the pointer variable points to". So ? the example 
n P:=y\X; n indicates that a pointer to X is found (constructed) and this 
pointer is assigned to P. Naturally, P must be a type of pointer to the same 
type that X is. 

Similarly, n PA:=Y; n expresses that what the pointer P points to is assigned 
the value Y. 

The form ,! AP:=X ,! is illegal because AP cannot be used on the left of an 
assignment. ■ ~ft*A& [s <U-o jv^v"^ "&T *- b©fo*#Uu 

In summary then: 

SYMBOL MEANING 

A.X CONSTRUCT A POINTER TO X 
PA REFER TO WHAT P POINTS TO 



POINTER SYMBOLS - FIGURE 3.23 



As an example in using pointers, let's construct an array of integers 
and create a pointer to the array which can be used to search the array 
for some value (e.g. the value 3). If that value is found, we will change 
the value 3 to -9.. 



TOPE 

ARY = ARRAY [1..100] OF INTEGER; 



VAR 




XARRAY 


: ARY, 


PTR 


: A ARY, 


I 


: INTEGER; 



"ASSUME XARRAY IS INITIALIZED HERE" 

PTR:=AXARRAY; 

FOR I:= 1 TO 100 DO 

IF PTR/^l] = 3 

THEN PTR/\£l] := -9 
I FEND ; 
FOREND; 



USE OF POINTERS - FIGURE 3.24 
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In figure 3.24 the pointer variable PTR is declared to be a pointer to 
type ARY. Note that variable XARR AY is type ARY. The statement 
n PTR: = AXARRAY; n constructs a pointer to.X ARRAY and assigns this 
pointer to the pointer variable PTR. In the IF statement, we want b> 
check the contents of each element (integer) in the array, XARRAY. PTR 
is a pointer to XARRAY. PTR A means what the pointer points to; the 
pointer poincs to XARRAY. PTRA then is XARRAY. J?TRA [3 j re fere nee s the 
third element in the array pointed to by PTR. 

This interesting reference notation can be carried even further. If a 

pointer XPTR points to an array and the elements of the array are strings 

(length 10) of characters, then to reference the 2nd, 3rd, and 4th 

characters in the string which is the 3rd element in the array, the reference would 

be XPTRA[_3"](2,3). 

RECORDS I ^ ^l^AJAOt \> W\T<**| 

So far all the data structures that we have discussed have been 
homogeneous. That is, all the elements have been identical. How 
does SWL enable us to create _ a da ta s t rue tur e ._ JjaaJL-jcumtaJLns^Qii-. 
bpj^gen^jjjs^eleme^tSi? It is done with a data structure called the 
record. 

The record is introduced with the reserved word RECORD and terminated 
with RECEND. Each of the constituent elements in the record are called 
fields. 

Figure 3.25 shows the conceptualization of a record" 

FIELDS RECORD 



SURNAME 


STRING (10) OF CHAR ' 


AGE 


0..100 


MARRIED 


BOOLEAN 


SEX 


BOOLEAN 


FINGERS 


0..11 




RECEND; 



THE CONCEPTUAL RECORD - FIGURE 3.25 

As illustrated in figure 3.25 the record is bounded by RE CORD -RECEND. 

Each field in the record is given an identifier (i.e. SURNAME, AGE, MARRIED, 

ETC.). As you can see the record can contain a mixture of types. In fact 

tjie^xeGQ^d— ea-n-~G<ontajL n_ a s a field any of the types discus sed so far, , 

including another record. 
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If we were to commit the conceptual record of figure 3.25 to SWL syntax 
the result would be as shown in figure 3.26. 

TYPE 

N^MEREC = RECORD 

SURNME : STRING(IO) OF CHAR, 

AGE : 0..100, 

MARRIED, SEX : BOOLEAN, 

FINGERS : 0..11, 

RECEND; 

VAR 

RECVAR : NAMEREC, 

RECARRY: ARRAY [l..lO^ OF NAMEREC, 

PTR : As NAMEREC; 

RECORD SYNTAX - FIGURE 3.26 



Figure 3.26 shows how the record syntax appears. In this example, the record 
was created as a type (NAMEREC). Subsequently, a variable RECVAR is 
declared that is type NAMEREC. The variable RECYAR (when assigned to 
storage) will contain enough space for each of the fields in type NAMEREC. 
The variable RECARRY is interesting. RECARRY is a ten element array. E^ch 
element in the array is a record of type NAMEREC. 



RECORD REFERENCES 

Once a variable is declared to be type record (or array of record) how 
do we access the individual fields of a record? Let's use the record 
variable RECVAR from figure 3.26. RECVAR is the variable name of a 
record. Whenever we use RECVAR by itself we are referring to the entire 
record. RRQi^ 

y^r^ Notice the use of the period here as a field separator. 
The period separates the field identifier (SURNAME) from the record name 
(RECVAR). If we wanted to jyy3ign_a^jsurn^ the proper assign- 
ment statement ^ TTfUi ranted 

to r tJLi£§B£&J^£^ the surname^ in the record we 

might^jise »BJ^^ 



Consider the pointer PTR in figure 3.26. How would we initialize this 
pointer variable to point to RECVAR? Answer: M PTR := A RECVAR;" . 

Once we have such a pointer, how could we use the pointer (instead of the 
record variable RECVAR) to initialize the age field to 15? Answer: 
PTRA.AGE:-=15;. In this example, J^R^jB9iSJE£ ,.t?^ he record and is a 
correct substitution for the variable name RECVAR. ~™ ~~~ ~" -• 
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Continuing, in figure 3.26 an array of records is declared as RECARRY .. 
This array has 10 elements each one containing a record. How would we 
refer to the last 5 characters of the surname field of the 7th record 
(element) in the array? Answer: RECARRY [7] • SURNAME (6,*).. 

Our final example is a common one for programmers who deal with linked 
lists. How can we construct a forward pointing linked list: This 
problem is illustrated in figure 3.27. 



START POINTER 



REC1 



REC3 




A FORWARD LINKED LIST - FIGURE 3.27 



Notice (in figure 3.27) how each record contains a pointer to the next 
record. The last record contains an empty pointer (NIL). A start pointer 
is needed to locate the first record in the list. Each record contains 
some value (shown as integers in this example). 

How would we represent this interesting data structure in SWL? 



MODULE LINKED LIST; 


PROC [XDCL] MAIN; 


TYPE 


REG = RECORD 


FPTR:ARE(U 


VALU: INTEGER 


RECEND; 


VAR 


STARTPTR:AREC, 


REC1,REC2,REC3,REC4 


STARTPTR :=-=ARECl; 


REC1. FPTR 


•=AREC2; 


REC2. FPTR 


•=A REC3 ; 


REC3. FPTR 


■=AREC4; 


REC4. FPTR 


'= NIL; 


REC1. VALU 


'= .3; 


REC2. VALU 


■= 6; 


REC3. VALU 


'= -5; 


REC4. VALU 


= 421; 



REC; 



PROCEND MAIN ; 
MODEND LINKED_LIST; 



LINKED LIST IN SWL - FIGURE 3.28 
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The example in figure 3,28 is a nice illustration, but lacking in its 
applicability to real programming practice., From this example we can 
see how to construct the structure shown in figure 3.27. The problem 
with figure 3.28 is that our program states explicitly how many records 
exist (in this example - four). In a real programming problem the 
number of records would change dynamically and we would have to add new 
records onto our list and delete records from the list, as required by 
the dynamic execution of the program. 

This dyn amical location an d fre eing of r ecords (or space l^jJA^be^^coyejced^ 
later under the topic ofjtqrage mana geme nt . 



SETS 

The SWL notion of a set follows reasonably closely the mathematical 
concept of set. A set' is simply an accumulation of elements (members). 
The elements can be identifiers (an ordinal), characters, boolean, or 
integers. The set members have no order. We cannot say that some member 
is the first member. However, we can place members in the set, delete 
members from the set, and determine whether a given member exists at the 
present time in the set. Of course, we can create both empty and full 
sets. 

Figure 3.29 illustrates the kinds of sets allowed and the syntax for 
declaring sets. 

TYPE 

A = SET OF (RED, GREEN, BLUE), "ORDINAL SET 11 

B = SET OF 0..17, "INTEGER SET" 

C = SET OF "A'.^'Z 1 ; "CHARACTER SET" 

VAR 

ORDSET : A, 

INTSET : B, - 

CHRSET : C; 



DECLARATION OF SETS - FIGURE 3.29 

In figure 3.29, type A is a set of the ordinal identifiers ( RED, GREEN, BLUE ) , 
That means that there are three possible members for the set type A. When 
a variable such as ORDSET is declared, it is a set variable. If ORDSET is 

9 9 * 

empty then it contains no members. If ORDSET is full then the members 
RED, GREEN, and BLUE are all present in the set. 

The obvious questioii then is how do we create empty and full sets? How 
do we place members in the set and remove members from the set? 

We use a conversion function to convert identifiers (or constants) into 
set members. For example (using figure 3.29) $a[rED^ is a conversion 
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function that converts the identifier RED into the set element RED belonging 
to the set type A. Since we have a variable ORDSET^ we could initialize (or 
assign) the member RED to the variable ORDSET by writing: 
M ORDSET : = $a[RED]} m ^ If we wanted to initialize (or assign) two members 
into ORDSET we could write: "ORDSET := $A[RED,BLUE] ;" . 

The empty set is constructed by having no members between the square 
brackets. For example (using figure 3*29) to make the variable INTSET 
empty we could write: INTSET := $B[];. If we wanted to place all the 
members in CHRSET we could use one of two methods 

1) create an empty set and complement the empty set 
(giving a full set). 

For example: 

CHRSET := NOT $C[3j 

OR 
CHRSET := NOT (CHRSET XOR CHRSET); 

OR 
CHRSET := NOT CHRSET XOR CHRSET; 

2) write out each and every member of the set. 
For example: 

CHRSET s = $c[ ! A', »B ! , ! C ! , 'D 1 , ? E», ! F ! , 'G 1 , 

'H 1 , »I' f ! JV tK! 5 tLT , !M? , ?N! , 
•0', ! P ! , ! Q', ! R ! , f S», iT ! , ! U T , 
»V ! , 'W, «X' f ! Y», 'Z']; 

MAKING FULL SET - FIGURE 3.30 



After seeing the two methods you would probably choose the first method 
whenever number of members in the set is large. 

Now that we know how to assign members to sets we should look at the kind 
of set operations that exist in SWL. These operations are summarized by 
example in figure 3.31 below. 
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TYPE 

A = SET OF 0o.5; 
VAR 

SETA, SETB, SETC: A; 
B: BOOLEAN; 



M ASSIGN MEMBERS TO A SET" 
SETB := $A[2,0,1]; 

"INCLUSE OR OF TWO SETS' 1 
SETC := SETB OR $A[4,0,l]; 

"LOGICAL PRODUCT (AND) OF SETS" 
SETA := SETB AND SETC; 

"SET IDENTITY (or equality)" 
B := SETA = SETC; 

"SET MEMBERSHIP " 

B := 5 IN SETA; 

"SET INEQUALITY " 

B := SETA /= SETC; 

"SETA IS CONTAINED IN SETC " 
B := SETA<=SETC; 

"SETA CONTAINS SETC " 

B := SETA>=SETC; 

"SET DIFFERENCE, THE SET" 
"CONSISTING OF ELEMENTS OF THE " 
"LEFT OPERAND THAT ARE NOT ALSO" 
"ELEMENTS OF THE RIGHT OPERAND " 
SETA := SETC/r^$AQ,53; 

"SYMMETRIC DIFFERENCE, THE SET " 
"OF ELEMENTS CONTAINED IN EITHER" 
"SET BUT NOT BOTH SETS" 
SETA := SETC XOR *AO-,s:K 



"RESULT" 
"0,1,2" 

"0,1,2,4" 

"0,1,2" 

"FALSE" 
"FALSE" 

"TRUE" 
"TRUE" 
"FALSE" 



"0,2,4" 



"0,2,4,5" 



SET OPERATION EXAMPLES - FIGURE 3.31 
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/ STORAGE MANAGEMENT 

We are often faced with the programming problem of managing storage 
efficiently. We want to be able to use the storage space efficiently 
and to access the space efficiently. The statements presented in this 
section help accomplish these goals. 



THE UNIVERSAL HEAP 

The universal heap is an area associated with the users program storage 
that can be managed explicitly by the user. Two statements are provided. 
The ALLOCATE statement is used to assign (or use) space in the universal 
heap. When the user allocates some type to the universal heap,SWL reserves 
enough space for the type and returns a pointer to the space to the user. 
Using the pointer, then, the user may access the space, store information 
into the sp- ce and retrieve data previously stored into the space. If the 
space cannot be allocated the jjojjn^x^is^JL^J 10 N ^^ 

When the user no longer needs the reserved (allocated) space the FREE 
statement may be used to make the space available for use later on in the 
program execution. 



' 9 



Any data type may be allocated explicitly by the user. In practice, 
however, the array, record, and sequence (to be discussed shortly) types 
are most often allocated. 

Lets examine the use of explicit allocation with respect to RECORDS. In 
this example, we will create a linked list by allocating space in the 
universal heap. See figure 3.27 for a diagram of the forward linked list. 

PROC [xdcl] MAIN 
TYPE 
R = RECORD 
FPTR:AR, 
VALU: INTEGER; 
VAR 
PiTEMPTRsARl 

N: INTEGER ; 

READ(N) ; M FIRST ALLOCATE" 

ALLOCATE PS 

IF P=NIL 

THEN WRITE ( 'NO ALLOCATE ' ,EOL) ; 

ELSE PA.FPTR:=NIL; 
PA.VALU:-= N; 
IFEND; 



READ (N); "SECOND ALLOCATE" 

ALLOCATE TEMPTR 5 

IF TEMPTR = NIL 

THEN WRITE ( ! N0 ALLOCATE » ,EOL) ; 
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ELSE PA.FPTR:==TEMPTR; 

TEMPTRA.FPTR:=NIL; 

TEMPTlV\.VALU:=N; 
IFEND 



STORAGE ALLOCATION - FIGURE 3,32 

Naturally, these allocate statements would be in some repetitive statement 
not written in line, as shown in the example in figure 3.32. 

If we were through using our linked list and wanted to free all the 
allocated records we would have to work our way down the linked list 
freeing each record in turn until we reached the record containing a 
forward pointer of NIL. 

This successive freeing is illustrated in figure 3.33. 

PTR 




TEMPTR :=PTR 

WHILE TEMPTR /=NIL DO 

PTR := TEMPTRA.FPTR; 

FREE TEMPTR; 

TEMPTR :=PTR; 

WHILEND; 



FREEING A LINKED LIST - FIGURE 3.33 




fylloaxti^*^^ (Frt %$*-') 
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SEQUENCES 

The sequence type represents a storage structure whose components are 
referenced through sequential accessing. Once a sequence (variable) 
is declared there are qnlxJEgojoperations that can be per forme d r NEXT 
and RESET. This sequential access to storage is analogous to the 
sequential file access provided by the READ statement. 

When a sequence is declared a definite measure of the space required by 
the sequence must be provided, ^T he NEX T statement is used b oth to enter 
va lues into the sequence and t OL_£emov:e^QX-jDbta Li nX~viriues from the se quence (< 
The reset statement may be used to place the sequence pointer so that the 
NEXT statement will access the first element in the sequence. 

When declaring the space required by a sequence the form "REP J N OF type" 
is used. That is the sequence must be large enough to hold N repetitions 
of type.. The example in figure 3.34 illustrates how we use the sequence 
as a data type. 



MODULE SEQUENCEJTEST ; 
PROC [XDCL] MAIN; 
TYPE 

A = SEQ(REP 10 OF INTEGER) ; 
VAR 

Pr/VINTEGER, 

ASEQ : A, 

I : INTEGER; 

"PLACE 10 VALUES IN ASEQ" 
FOR I := 1 TO 10 DO 
NEXT P IN ASEQ; 
PA:=I*5; 
FOREND; 

"WRITE ALL VALUES IN SEQUENCE" 

RESET ASEQ; 

NEXT P IN ASEQ; 

WHILE P/= NIL DO 

WRITE (PA:5,E0L); 

NEXT P IN ASEQ ; 

WHILEND; 

PROCEND MAIN ; 
MODEND SEQUENCEJTEST; 



SEQUENCE SYNTAX - FIGURE 3.34 



Rev. B 3 „26 



The statement "NEXT P IN ASEQ;" provides a pointer to the next element 

in the sequence ASEQ. To access this element we must use the pointer 

reference PA. So 5 to place a value in the sequence we use a statement 
like "PA:-1*5;" 

To access the values in the sequence first RESET the sequence and then obtain 
successive pointers to elements in the sequence with the "NEXT P IN ASEQ;" 
statement executed repetitively. Notice that when the end of the sequence is 
reached, the "NEXT P IN ASEQ" will return a pointer value that is NiL 
(indicating the end of the sequence). 



VARIABLE ATTRIBUTES 

When variables are declared certain attributes may be associated with the 
variable. We will consider two classes of attributes: 1) storage 
attributes and 2) scope attributes. 

Recall that the general form of a variable declaration is "VAR identifier: 
type;". When we wish to add attributes to the variable declaration the 
form becomes "J/Aj^jien^ That is, the attributes 

are added after the colon (:) and before the type and the attributes are 
enclosed in square brackets* 

STORAGE ATTRIBUTE 



A variable declared without any attributes becomes an automatic variable. 
Storage for this type of variable is allocated automatically when the block 
in which the declaration exists is entered (at execution time). The 
storage for such a variable is freed upon EXIT from the block in which it is 
declared. When a variable is given the ["STATIC] attribute the automatic 
allocation is not changed. But, the storage for the variable is not freed 
upon exit from the block. In fact, once allocated the storage for the 
variable remains allocated for the lifetime of the program. This can be 
very helpful for counters (for instance) where the counter should not be 
re-initialized (or re-allocated). 

SCOPE ATTRIBUTES 

The scope attributes are ^XDCLJ and Q XREF J • Whenever either of these 
attributes are used^the variable i^ny im ^fTurt m ^T^^^j . 6S - a ™~*-»~-^ 

The QxDCLj attribute indicates that the variable is declared, in this ? a ,| ^a 

module, and this declaration is available to other modules. |)aei^\^t ^VfU^lPi^J 9 ^^ &^ 

The £xREFj attribute indicates that the variable is used (j^ferenced)^, 
in this^mc^duj^^and ttat^h^ajcj^^ 
s'ome other module. ~~ 
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Prior to program execution theLxREF]and[XDCL] variables (with the same 
identifier) are bound together so that only one occurrence of the variable 
actually exists in storage. To effect this "linkage" the[XREFJ and[XDCL] 
variable declarations should express the same type. 

The example in figure 3.35 illustrates the use of [xREFjandQcDCLJin two 
modules. 



module pass1; 

var syntaxjtable 
: [xdclJ array 

Q..100] OF CHAR; 

"VARIABLE SYNTAXJTABLE" 
"DECLARED XDGL HERE SO THAT" 
"IT CAN BE ACCESSED " 

"FROM ANOTHER MODULE " 



module pass 2; 

var syntaxjtable 
: £xref} array 

jjL..10(fj OF CHAR; 

"VARIABLE SYNTAXJTABLE" 
"DECLARED XREF SO THAT " 
"THE ACTUAL STORAGE " 

"ALLOCATED IN PAS SI WILL BE USED" 



MODEND PASS1; 



MODEND PASS2: 



XDCL and XREF ATTRIBUTES - FIGURE 3.35 



As shown in figure 3.35 only, one, one-hundred-element array will be 
allocated storage. This storage allocation is from MODULE PASS1. Any 
use of the variable SYNTAXJTABLE from MODULE PASS 2 will really be 
referencing the storage allocated in MODULE PASS1. 

If variables are declared and used in only one module, then there will be 
no need for the [XDCL] and [XREFj attributes. 



Our example shows these attributes with an array variable, 
type of variable can be madeQXDCLjor used as[XREF] 



Of course, any 



PACKED VARIABLES 

The ability to specify that a variable is packed, is the SWL method for 
providing the programmer a choice between compacting data and access time. 
Generally, a packed variable (such as a packed array) will save space but 
require greater time to access any individual element. 

There are only two data types that can be packed - arrays and records. 

Although the actual packing algorithm may differ from one language 
implementation to another the concept of the trade-off between storage 
space and access time is a valid one 
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Take a look at the example in figure 3.3 6 • 

VAR 

X : ARRAY Q...100] OF 0..15, 

y : [[packed^] array £i..ioq] of 0..15; 

PACKED DATA - FIGURE 3.36 

In figure 3.36, both arrays contain one hundred elements. In both cases 
the array contents is in the range to 15. The variable X will optimize 
access time at the expense of storage space. The variable Y will 
optimize storage space at the expense of longer access time. It f s your 
choice - access time or efficient storage. Generally, you can*t have both. 

The actual packing algorithm (or number of bits used) need not concern us 
here. 



VARIABLE INITIALIZATION 

Occasionally, it would be nice if we could initialize a variable along 
with the declaration of the variable. That is, not have to write a 
separate statement to perform the initialization. At the present time 
only [STMICQ variables may be initialized. ~™ 



To initialize a variable we simply add an assignment onto the end of 
the variable declaration. 

Some simple instances of variable initialization are shown in figure 3.37. 



VAR 
X 
Y 
R 
Z 

c 



TSTATICj INTEGER := 0, 
[STATIC] BOOLEAN := TRUE, 
[STATIC] REAL := 1.537, 
[STATIC] (RED, BLUE) := RED, 
[STATIC] CHAR := T T ! ; 



VARIABLE INITIALIZATION - FIGURE 3.37 

Of course more complicated data types may be initialized too. For 

instance, RECORDS-! ARRAYSi and SETS may be initialized. When arrays are I 

initialized the values for each dimension are enclosed in square brackets 

[]. When records are initialized each record is enclosed in square brackets. 

As an example, let ! s initialize a two-dimensional array as shown in 
figure 3.38. 
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VAR 

X : [[STATIC] ARRAY fl . .21 OF 



TIC] ARRAY ri..2l ( 

ARRAY L3..5J OF INTEGER 
:= [[6,7,-3], [5,7,2^]; 



ARRAY INITIALIZATION - FIGURE 3.38 

Notice that array X is an array of an array. Each element in the first 
array is an array of three elements. So, two groups of three integers 
are required for initialization. The initialization expression 
C C 1 £ 3 1 contains two groups of three integers » 

As one last example of initiaH consider the variable R which is 
a record containing a record, as shown in figure 3.39. 

VAR 

R : ^STATIC} RECORD 

AGE: 6.. 66, 

MARRIED, SEX: BOOLEAN, 

DATE: RECORD 

DAY: 1..31, 
MONTH: 1..12, 
YEAR: 70.. 80 
RECEND 
RECEND 
:= [23, TRUE, TRUE, f3,5,73^j]; 

RECORD INITIALIZATION - FIGURE 3.39 

In figure 3.39 ,each record initialization is enclosed in square brackets!. J» 
The initialization values are explained in figure 3.40. 

FIELD VALUE 



R. 


AGE 


23 


R. 


MARRIED 


TRUE 


R. 


SEX 


TRUE 


R. 


DATE. DAY 


3 


R. 


DATE .MONTH 


5 


R. 


DATE .YEAR 


73 



RECORD INITIALIZATION VALUES - FIGURE 3.40 



3-30 



Sets may ba initialised-: fcoo-> by piscine; the initialised set members I 

VAR 

S : CSTATIO SET OF D..T 

SET INITIALIZARION - FIGURE 3.MD-1 

Strings may be initialized by placing the initialization values in 
single quotes. Also-, the CAT operator may be used in string initial- 
ization as shown below: 

VAR 

SI : CSTATIC3 STRING Cs) OF CHAR := 'ABCDE'-, 

S5 : CSTATIC3 STRING (iq)0F CHAR 

:= 'STUVU' CAT 'ABSBC'i 
STRING INITIALIZATION - FIGURE 3.MD.E 

NOTE Pointers may not be initialized. 



TYPE CONVERSION 

The operations of assignment, comparison, and arithmetic are 
defined only for operands of equivalent types. When it is necessary 
to operate on operands that do not meet the requirements of type 
equivalence the type conversion functions must be used. 

There are two classes of type conversion. The primitive conversions 
are described on page 2-15. Structured conversions are not available 
in ISWL but will be provided in SWL. 
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I/O REVISITED 

In our earlier discussions of Input and Output (the READ and WRITE 
statements) we did not discuss the problem of reading more than one 
line of data from a terminal. Our previous I/O discussions were correct 
for reading data from a data file. When we have a data filfe^ all the 
data exists in the file at the tibe ;the f ile is opened (if it is a file 
to be read) . ; ; ) 

In contrast to this, terminal input is entered ohMliny^at a-lime. Each 
1 ine a en t er e d. is in, ^fX^jcJt^a^^ane line file., So to read a second line from 
a terminal we Stttus totfewlnd 1 tile t ermina 1 input f ile Ytf itte the -st a tefrient i V & & 
n REWIND(.INPUT);'J ^ ~ 

As an overview, then, we can see that a program written to read data from 
a file will not in general read terminal input successfully.^ And, a 
program written ? to feacfc terminal data will not work ctrrect'ly when the 
data is provided via an existing file. The difference between the two 
programs will be the "REWIND ( INPUT ) ;" statement . 

Assume that an ISWL program intends to read four (4) lines of data« The 
data is integer and we wish to sum up the integer values. ; 5 ' 

An ISWL program to accomplish this from a data file would have the 
following statements: 

MODULE FILEIO; 

PROC £XDCL]MAIN; r r 1 :: ' ■;' 

VAR I, S: INTEGER 

S:=0; ' , 

; READ(I); 
" M : WI1ILE NOT #EOF(INPUT)DO ! '' \ ' " 
S:=S+I; ; " : ' '• : -' :: ' i '' ;; '"" ' j: - nr ■- s " ; '> v; -' : -^ r ^"^ -;T- '^" -V 
READ(I); 
WHILEND; 
■''"'"■^''''WRiTECSjEbl,')'; 
PSOCEND MAIN ; 
MODEND FILEIO; 

READING INPUT FRCM DATA FILE - FIGURE 3.41 

In figure 3.41 the program will read data until it reaches the end of file, 
All read statements look like they are reading from file input however, 
using control language statements we will (at load time) change file 
input to some data file. 
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To read a similar four lines from^a terminal the following program could 
be used: 



MODULE TEKMINALIO; 

PROC JXDCL] MAIN; 

VAR I,S : INTEGER; 

S:=0; 
f REPEAT 
I READ(I); 

JrWHILE NOT #EOF( INPUT) DO 
I S:=S+I 5 . 
JREAD(I); 
L WHILEND; 

REWIND (INPUT); 
»• UNTIL #EOF( INPUT); 

WRITE (S,EOL); 

PROCEND MAIN; 

MODEND TERMINALIO 



READING INPUT FRCM TERMINAL - FIGURE 3.42 

In figure 3.42 the program reads data until it reaches end-of-file. 
This condition really signals end-of-line since each line is terminated 
by an end-of-file. Then the program does n REWIND( INPUT) ; M which gets 
set for the next line. If the terminal user keys in an empty line 
(carriage return only) the end-of-file will be set and the program will 
exit the REPEAT statement. 

Actually, the program of figure 3.42 could be used for file I/O if the 
"REWIND (INPUT);" statement was removed. 
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CHAPTER 4 
ADVANCED SWL 



This chapter includes discussions about the more advanced features 
supported by SWL. The material presented will cover Procedures, 
Functions, Adaptable types, Unions, Conformity case, Variant records, 
Labels, Control Statements, Advanced I/O, Representation Dependent 
facilities, Standard Functions and Compile Time options. 
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PROCEDURES 

Before studying this section you may wish to review the material on 
Procedures, Block Structure, Call by Value, Call by Reference, and 
Scope of Identifiers presented in Chapter 1. 

A procedure is a convenient way of declaring some variables and execution 
time statements in one place in a module and referring to (or calling) 
the procedure from some other location in the module or from some other 
module. 

A procedure is delimited by the PROC and PROCEND statements. The 
simplest example of a procedure declaration is a procedure that has no 
parameters passed to it. This form of procedure normally uses global 
variables to obtain or store data. 

This very simple procedure declaration is shown in figure 4.1. 



"GLOBAL VARIABLE DECLARATION" 

VAR I, J, K: INTEGER; 

. 

"PROCEDURE DECLARATION" 

PROC ADD; 

K:=I+J; 
PROCEND ADD; 

"PROCEDURE CALL" 

PROC [XDCL]MAIN 

READ (I,J); 

ADD; 

WRITE (K,EOL); 

PROCEND MAIN; 



SIMPLE PROCEDURE DECLARATION & CALL - FIGURE 4.1 



The example in figure 4.1 illustrates both the simple procedure declar- 
ation and the procedure call. In this example, variables I, J, and K are 
global variables. Their scope includes both procedure ADD and procedure 
MAIN. Procedure ADD, when called, adds the global variable I to the 
global variable J and assigns the result to global variable K. Note 
that no parameters are actually passed to the procedure ADD directly. 

In procedure MAIN, figure 4.1, the first statement reads values for 

the global variables I and J. Then the procedure ADD is called (by the 

line "ADD;"). Procedure ADD does its computation and returns 

(at the "PROCEND ADD;" statement) to procedure MAIN. The next statement in 

procedure MAIN writes the results (K). 



Rev. B 4-2 



This example illustrates the declaration and call to a procedure using 
the global variable mechanism for communication. This mechanism pro- 
vides good communication, but does not provide much protection for the 
global variables. 

Next, we want -to describe the passing of parameters to a procedure. When a 
procedure is declared, and parameters are specified in the declaration, 
these parameters are called FORMAL parameters. 

When a procedure is called and parameters are placed in the call the 
parameters are known as ACTUAL parameters. These concepts are shown 
in figure 4.2. 

PROC ADD (FORMAL PARAMETERS); 

PROCEND ADD; 

i 

PROC [XDCL]MAIN; 

ADD (ACTUAL PARAMETERS); 

. 



PROCEND MAIN; 
ACTUAL and FORMAL PARAMETERS - FIGURE 4.2 



The forma 1^ parameters and actuaj^parameters must ag ree in number , 

\ 

The formal parameters also declare whether parameter passing is done by 
value or by reference. If the parameter passing is by value then a 
copy of the actual parameter is made for the procedure which is called. 
This mechanism insures that the procedure called will have the value of 
the actual parameter and that the procedure called cannot change the 
actual parameter. This provides protection for the actual parameter. 

If the formal parameter indicates a call by reference then a pointer to 
the actual parameter is passed to the procedure called. In this manner, 
the called procedure can read and alter the actual parameter. 

It should be clear that a call by reference parameter provides excellent 
communication but provides limited protection (or security). The call 
by value parameter provides excellent protection (or security) but poor 
communication. 

Now we can modify the simple add procedure of figure 4.1 to include both 
call by reference and call by value parameters. Notice the syntax of 
the parameters. 
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MODULE PROCJttTH_PARAMETERS; 
PROC ADD (REFM: INTEGER; 

VAL N,P:INTEGER;); 

M:=N+P; ***™°^ 
PROCEND ADD; 

PROC [XDCL] MAIN; 

VAR I , J, K: INTEGER; 

READ(J,K); 

ADD(I,J,K); 

WRITE(I,EOL); 

PROCEND MAIN ; 

MODEND PROCJWITH_PARAMETERS ; 

PROCEDURE WITH PARMETERS - FIGURE 4.3 

In the example in figure 4.3 notice that in the procedure declaration 
for ADD three (formal) parameters are declared. The first (M) is call 
by reference and the last two (N,P) are call by value. The procedure 
then uses the variables M, N and P to compute some result. 

Referring now to procedure MAIN in figure 4.3 notice the local variables 
I, J and K. These variables cannot be accessed by procedure ADD directly 
because the scope of the identifiers (I, J, and K) is limited to procedure 
MAIN . 

At execution time the first statement executed will be the n READ(J,K); n 
statement. The next statement M ADD(I,J,K); n calls the procedure ADD and 
passes the three parameters. Since the 2nd and 3rd parameters are call 
by value (see PROC ADD declaration) a copy of the actual parameters 
(J,K) is made for the procedure ADD. Inside procedure ADD these two 
paramters are known as N and P. From the viewpoint of procedure ADD 
variables N and P are local variables and they are copies of the actual 
parameters J and K. 

The actual parameter I, however, is different. In the procedure ADD 
declaration the 1st (formal) parameter is declared to be call by 
reference. This means that procedure add will receive a pointer 
(reference) to the actual parameter (I). Notice that this means that 
any changes (assignments) to the 1st formal parameter within PROC ADD 
will modify the actual parameter (in this case I). 

The call by reference for the 1st formal parameter is essential in this 
example because it provides the mechanism for the procedure ADD to 
return the result to the procedure MAIN. 

After procedure ADD is completed (the "PROCEND ADD; 11 statement is executed) 
control returns to the write statement in procedure MAIN and the result 
I is written to the output file. 
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What would happen if the 1st formal parameter (M) had been declared to 
be call by value instead of call by reference. This is illustrated 
be low : 

PROC ADD (VAL M: INTEGER; 

VAL N,P: INTEGER;); 
M:=N+P; 
PROCEND ADD; 

In this case, when the procedure add was called, a copy of the actual 
parameter (I, which is undefined) would be made for the procedure to 
use. After the procedure ADD statement n M:==N+P; n is executed, the 
result value M would be a local value (local variable) • When procedure 
ADD returns to Procedure MAIN, all local variables will be destroyed. So, 
the value of M we so carefully computed would be destroyed. The actual 
parameter (I) would remain undefined and the write statement, would write 
out some undefined quantity for the value of I. 

It should now be apparent that we must carefully declare formal parameters 
according to their use considering both communication and protection 
of variables. 

FUNCTIONS 

Functions are similar to procedures. Their declaration is almost 
identical with the exception of a return type, added on at the end, that 
declares the type of the function. Functions normally return a value. 
This value can then be used in other computations. 

Because the function returns a value, we cannot place the function call on a 
line by itself (what would happen to the result?). Therefore, a function call is 
normally embedded in some other statement (such as an assignment or IF 
statement) • 

Let ! s write our ADD routine as a function and see how it differs from the 
procedure use of the same routine. 

MODULE FUNCTION_ADD • 

PROC ADD (VAL N,P: INTEGER) INTEGER; 

ADD:=$I+P; 

PROCEND ADD; 

PROC [XDCL-] MAIN; 

VAR I, J, K: INTEGER; 

READ (J,K); 

I:=ADD(J,K); 

WRITE(I,EOL); 

PROCEND MAIN; 

MODEND FUNCTION ADD; 



FUNCTION DECLARATION - FIGURE 4.4 
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In the example in figure 4.4 notice the declaration of the function ADD. 
It looks just like the procedure declaration except for the reserved 
word "INTEGER" at the end of the line "PROC ADD (VAL N,P:INTEGER) INTEGER;". 
This word does two things: first, it specifies that this is a function 
declaration (instead of a procedure declaration); and second, it specifies 
that the function returns a type which is an integer. Or saying it 
differently, the function returns an integer value. 

Now, inside the function "ADD", the line that computes the result 
n ADD:=N4-P; n adds NtP and assigns the result to the function name l 
Yes, this is how the function obtains its value. 

Looking at the call to the function (from procedure MAIN) "I:= ADD(J,K); n , 
we see that the actual parameters J and K are sent to the function 
and that M ADD(J,K) ; n must result in some value because the value is 
assigned to I. The value of "ADD(J,K) M is called the function value. 
You can see how the function name in the call is part of a larger 
statement. 

One final comment on the restrictions on functions. Functions can 

not return all call types. A function can return an integer, character, ordinal, 

boolean, real, or pointer result. ~ ~~~™™«™ ™_~_^. 



4-6 



NESTED PROCS and FUNCTIONS 

When procedures or /and functions are nested, we obtain security for 
the function or procedure itself as distinct from the parameters which 
are passed. 

For example, consider the program structure in figure 4.5. 



MODULE NESTED PROCS; 








PROC CCMPUTE; 






C 


VAR 









PROC TEST; 


T 




M 


VAR 


E 




P 


"EXECUTABLE STATEMENTS HERE" 


S 




U 


PROCEND TEST; 


T 




T 


" EXECUTABLE STATEMENTS HERE 11 






E 



PROCEND CCMPUTE ; 
PROC [XDCL] MAIN; 
CCMPUTE; 
PROCEND MAIN; 
MODEND NESTED_PROCS; 



M 
A 
I 
N 



NESTED PROCS - FIGURE 4.5 

In the example in figure 4.5 we see that procedures MAIN and CCMPUTE 
are at the outermost level. Procedure TEST is nested inside COMPUTE, 
This structure provides some shielding (protection) for procedure TEST. 

With this structure, procedure MAIN can call procedure CCMPUTE, BUT 
procedure MAIN cannot call procedureTEST. Only CCMPUTE can call TEST. 
So TEST can rely on CCMPUTE to validate variables and perform other 
computations which might be necessary for the correct execution of TEST. 

This kind of nesting structure is frequently used to provide protection 
for procedures or/and functions. 



XDCL and XREF ATTRIBUTES 

We discussed XDCL and XREF attributes with respect to variables in 
Chapter 3. The concept is equivalent for procedures and functions. 
These attributes are only needed when we wish to declare a procedure 
(or function) in one module and be able to refer to (or call) that 
procedure (or function) from another module. 
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Figure 4.6 below provides an example of this kind of referencing 
mechanism. 

MODULE FIRST; MODULE SECOND; 

/PROC [XREF] COMPUTE; ,/PROC [XDCL] CCMPUTE; 

proc: £xdcl] MAIN ; PROCEND C CM PUTE ; 

: MODEND SECOND; 

CCMPUTE; 

PROCEND MAI1S(; 
MODEND FIRST; 



XDCL and XREF PROCEDURES - FIGURE 4.6 



In figure 4.6 modules FIRST and SECOND would each be separately compiled and 
then loaded together. Note that procedure CCMPUTE is declared in 
module SECOND. In fact, no other declarations exist in module SECOND. 
The procedure COMPUTE (in module SECOND) is given the attribute XDCL. 
This means that the procedure is declared in this module and can be 
referenced from some other module. 

In module FIRST only the line "PROC [XREF J CCMPUTE;" appears to identify 
CCMPUTE. This line indicates that CCMPUTE is a procedure. The XREF 
attribute indicates that the procedure (CCMPUTE) will be referenced in 
this module (FIRST) and is declared somewhere else. Inside module FIRST, 
the identifier CCMPUTE is known as a procedure name. 

If procedure CCMPUTE had any parameters, the parameter list (formal 
parameters) worujMia^ in 

each MODULE. j And, the parameter specifications would have to "agreeTSr 
number, order, and type. The identifiers of corresponding parameter 
could, however, be different. 

We might also note that "PROC fXDCL] MAIN;" declares a procedure whose 
name is MAIN that is XDCL (declared here for reference elsewhere). 
This is a special procedure. The loader (a procedure) calls the 
procedure MAIN to begin program execution. Hence, we must have one 
procedure MAIN and it must be XDCL so the loader can call it. 



4-8 



ADAPTABLE TYPES 

Before we cover adaptable types lets examine a SWL function to sum (add) 
all the elements in an array and return the sum as a results 

MODULE SUMMATION; 

TYPE Q = ARRAY [l..lO] OF INTEGER; 
PROC SUM (VAL VECTOR : Q) INTEGER; 

VAR I: INTEGER; 

SUM :-= 0; 

FOR I:= 1 TO 10 DO 

SUM := SUM + VECTOR [l]; 

FOREND; 
PROCEND SUM ; 

PROC TXDCLlMAIN; 

VAR K: ARRAY [I..IO] OF INTEGER, 

RES, I: INTEGER; 
FOR I:= 1 TO 10 DO 
READ (K[I]) ; 
FOREND; 
RES:= SUM(K); 
WRITE (RES,EOL); 
PROCEND MAIN ; 
MODEND SUMMATION- 



SIMPLE SUMMATION FUNCTION - FIGURE 4.7 

From the structure of the program in figure 4.7 we can see that procedure 
MAIN calls (and uses) the function SUM. Notice that in MAIN an array (K) 
is declared to contain ten elements. Because MAIN calls SUM, SUM must 
also contain a declaration for an array (VECTOR). The annoying thing is 
that the array vector (type Q) also contains ten elements. 

Why is this a problem? If procedure MAIN were altered to read in twenty 
integers (and the variable declaration for K were also changed to be 
1..20) then we would have to change the function declaration also. In 
this example, the statement "TYPE Q =? ARRAY [1..10] of INTEGER;" would 
have to be changed to an array of 20 elements. 

This change of the function SUM is unfortunate. It would be much nicer 
if the function could change the nunber of elements in the array to suite 
(or conform to) the number of elements in the actual parameter. 

There is such a type in SWL and it is called the ADAPTABLE type. It is 
called ADAPTABLE because the formal type can adapt (to a limited extent) to the 
specification of the actual parameter. This process of ADAPTING takes 
place at execution time. Ue say "to a limited extent" because 
ADAPTABLE means adjustable size or bounds- The type of parameter 
cannot be adjusted- 
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In our example (figure 4.7) if the variable VECTOR were adaptable then 
we would have some problem with the statement "FOR I:= 1 TO 10 DO". 
If the variable VECTOR were adaptable its first element might not be 
one. Further, its last element would almost certainly not be ten. 
Our FOR statement must be able to adapt too. The problem can be 
expressed as one of being able to find out what the current bounds of 
an adaptable array are. In SWL, two functions exist to help us. The 
#L0 WERB0UND (a daptable array name, dimension) ^function jret urn js^an. integer 
whictTTs the^owerbou^ airra^^ 

f^fhis dimension pa ramete remakes it possible to use the lowerbound function" 
|j:o find the lowerbound in any dimension of the adaptable array. Similarly,) 
the #UPPERB0UND (adaptable array name, dimension) function is used to 
determine (at execution time) the upperbound of an adaptable array. 

Using these concepts we can rewrite the MODULE as shown in figure 4.8. 

MODULE BETTERJ3UMMATI0N; 

TYPE Q =ARRAY [*] OF INTEGER; 

PROC SUM (VAL VECT0R:Q) INTEGER; 

VAR Is INTEGER; 

SUM: = 

FOR I:= #L0WERB0UND (VECTOR, 1) TO 

# UPPERBOUND (VECTOR, 1) DO 
SUM:= SUM + VECTOR [l] ; 
FOREND; 
PROCEND SUM ; 

PROC [XDCL] MAIN; 

VAR K: ARRAY [l . . 10] OF INTEGER; 

RES, I: INTEGER; 

FOR I:= 1 TO 10 DO 

READ (K[l]) ; 

FOREND; 

RES := SUM (K) ; 

WRITE (RES,E0L); 

PROCEND MAIN; 

MODEND BETTER_SUMMATION; 

ADAPTABLE SUMMATION FUNCTION - FIGURE 4.8 

In the example in figure 4. 8, notice the statement "TYPE Q=ARRAY [*] OF 
INTEGER;". The asterisk [*] indicates that the array is adaptable and 
that the indices are integer. Inside the function SUM notice the way 
the FOR statement has been written to take on the lowerbound and upper- 
bound of the adaptable array. 

If we wish to read in a different number of integers, now we need only 
change procedure MAIN. No changes will be needed for the function SUM. 

We have succeeded in writing a more general purpose function. 
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ADAPTABLE SPECIFICATIONS 



Adaptable types are used only as formal parameters for procedures and 
functions. There are six data types which can be adaptable. These are 
ARRAYS, STRINGS, RECORDS, STACKS, jEQUEN^ *—— ^«_^ 

An adaptable array can be specified in a number of ways. Adaptable array 
indices are not limited to integers. Figure 4.9 illustrates some of the 
adaptable types allowed for arrays. 

TYPE 

"ADAPTABLE ARRAY WITH INTEGER INDICES" 
Q = ARRAY [*]0F REAL, 

"ADAPTABLE 2-D ARRAY WITH INTEGER INDICES" 
Rl = ARRAY t*l OF ARRAY C*J OF BOOLEAN, 
R2 = ARRAY t*,*l OF BOOLEAN, 

"PARTIALLY ADAPTABLE ARRAY WITH INTEGER INDICES" 

51 = ARRAY [3..*] OF CHAR, 

52 = ARRAY [*..53] OF REAL, 

"ADAPTABLE MRA^ WITH CHARACTER INDICES" 
T = ARRAY f*:CHA£] OF REAL; 



ADAPTABLE ARRAY SPECIFICATIONS - FIGURE 4.9 

In addition to adaptable arrays we may have adaptable strings. The string 
declaration is simple in that the string has only one type, character, and 
one length specification. In addition, the length specification must be 
integer. Figure 4.10 illustrates the aj^j^aj^e^string specification. 

TYPE 

STR = STRING (*) OF CHAR; 

ADAPTABLE STRING SPECIFICATION - FIGURE 4.10 

When we use adaptable strings inside a procedure or function we need a 
method of obtaining the string length of the actual parameter. The 
.ffiSTR LENGTH [ (adaptab le string variable name) function returns an integer 
value which is t h<^Iengtir*o^ lef^s tr ing variable name. This 

function is the string equivalent of the upper and lower bound functions 
for arrays. 

The record type may also be adaptable if one and only one of its fields 
are of adaptable type. 
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UNION OF TYPE 

Sometimes we have a need for a variable that can contain different types 
not simultaneously - but alternately. Two examples are indicative of 
this need. 

First, consider an array that contains pointers to different types of 
records. This is shown graphically in figure 4.11. 



ARRAY OF POINTERS 





ft* 


R2 










gp 












Rl 




NIL 





Rl 



R2 



ARRAY OF UNION OF POINTERS - FIGURE 4.11 



In figure 4.11 the array elements are pointers, some of which point to 
Rl-type records and some to R2-type records. To accomplish this, we must 
declare the array elements as UNION type. In this way, the array elements 
can be either union member type (i.e. a pointer to either type of record. 



This concept is expressed in SWL syntax below. 

TYPE 

Rl = RECORD 

A,B,C:INTEGER, 

RECEND, 
R2 = RECORD 

W,X,Y,Z: BOOLEAN, 

RECEND, 

UN = UNION (AR1,AR2), 

AR = ARRAY [1..1Q] OF UN; 

VAR 

PTRARY : AR; 

UNION SYNTAX - FIGURE 4.12 



4-12 



Another example uses the concept of union to allow the declaration of a 
procedure (or function) that can accept as an argument any one of several 
types. 

Unfortunately, at the present time only union of pointer types is allowed. 
But one day, union of other types will also be available. So in our 
example below we have a procedure which will free a linked list. This is an 
extension and generalization of the example in figure 3.33. The procedure 
will accept as an argument one of many types of pointer to linked list. 
We will show only the procedure declaration at this time. 



TYPE 

Rl = RECORD 

"Rl RECORD DECLARATION" 

RECEND, 
R2 --= RECORD 

"R2 RECORD DECLARATION 11 

RECEND, 
R3 = RECORD 

n R3 RECORD DECLARATION" 

RECEND, 
UN = UNION ( a R1,aR2,aR3); 



PROC FREELIST (VAL PTR:UN); 
PROCEND FREELIST; 

UNIONS IN PROCEDURES - FIGURE 4.13 



In figure 4.13 the union type. UN can contain a pointer to one of Rl, R2 
or R3 type records. The procedure FREELIST can accept as an actual 
parameter either of the three types of pointers. The contents of the 
procedure FREELIST will be discussed below. 



UNION OPERATORS 

There are three UNION operators. These are: 

OPERATOR MEANING 

: TYPE TESTING 

=: VALUE TYPE TESTING 

a: POINTER TYPE TESTING 



UNION OPERATORS - FIGURE 4.14 
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Of the three union operators illustrated in figure 4.14 only the v alue type 
Jtest^ Therefore, we will disci^ss'^^^ 

this operator onlyT 

VALUE TYPE TESTING 

The value type testing operator performs two operations. First, if the variable 
on the left is the same type as the current value of the union variable on the 
right the operator returns the boolean value TRUE; otherwise, the boolean 
value FALSE is returned. Second, when the boolean value is true then the 
variable on the left is assigned the current value of the union variable 
on the right. We can test to determine what type is currently in the 
variable and obtain the contents of the union variable. 



Keeping in mind that only unions of pointers are allowed at the present 
time we can finish the contents of the FREELIST procedure that we 
started in figure 4.13. 



"ASSUME RECORD TYPES DECLARED" 
"AS IN FIGURE 4.13 " 

TYPE 

UN = UNION UR1, A R2, A R3); 

PROC FREELIST (VAL PTR:UN); 
VAR PTR1:aR1, 

PTR2:aR2, 

PTR3 : aR3 ; 

IF PTR1:=: PTR 

THEN "CODE TO FREE Rl TYPE LIST" 

ORIF PTR2:=: PTR 

THEN "CODE TO FREE R2 TYPE LIST" 

ORIF PTR3:=: PTR 

THEN "CODE TO FREE R3 TYPE LIST" 

ELSE "ERROR" 
IFEND; 

PROCEND FREELIST; 

VALUE TYPE TESTING OPERATOR - FIGURE 4.15 

In the example In figure 4.15, the formal parameter "PTR M is a union of 
three possible pointers to three different records. The variable declaration 
identifies three variables each one is a pointer to a different type record. 

In the statement "IF PTR1 :=: PTR", the value type test operator :=: tests 
the jiype of PTR1 (p]I^^ the cur renTType^^ 

61 the contents of the union variable PTR.___ — ~—~ __™ _._«--* 
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If the types are not identical, then the Boolean result FALSE is returned 
and the IF statement progresses to the next ORIF clause* If the types 
match, then the boolean value of :=: is TRUE and the variable PTR1 is set 
(or assigned) to the current value of the union variable. When the 
result of the value testing operator :=: is true, the THEN clause of the 
IF statement is executed and the code to free the list is executed. 

You can see how much effort must be used to isolate and use the current 
contents of the union variable. 



VALUE CONFORMITY CASE 

The value conformity CASE statement provides a method of clearly identifying the 
case to be performed depending upon the current value of a union variable. 
The value conformity case, then, is an extension of the IF and ORIF 
clauses (in figure 4.15) necessary to isolate the current value of a union 
and execute the appropriate statements. 

Lets rewrite the FREELIST procedure of figure 4.15 using the value 
conformity CASE statement. 

,f ASSUME RECORD TYPES DECLARED" 
"AS IN FIGURE 4.13 M 

TYPE UN = UNION ( A R1, aR2, a R3) ; 
PROC FREELIST (VAL PTRrUN); 
VAR PTR1 :AR1, 

PTR2 :AR2, 

PTR3 :AR3; 

CASE :=: PTR OF 

=PTR1= "CODE TO FREE Rl TYPE LIST" 

=PTR2= "CODE TO FREE R2 TYPE LIST" 

=PTR3= "CODE TO FREE R3 TYPE LIST" 

ELSE "ERROR" 

CASEND ; 

PROCEND FREELIST; 

VALUE CONFORMITY CASE SYNTAX - FIGURE 4.16 

You can see how this value conformity CASE statement makes the program 
text clearer. The first line of the CASE statement "CASE :=: PTR OF" 
clearly identifies the statement as J^ 

varl^^ etc.) clearly indicate what 

tfilTalternatives are. With the conformity case statement, we do not need 
to bother with the TRUE-FALSE values normally associated with the type 
testing operators. 

When the type of a case (i.e. =PTRl=) does match the current type of the 
union variable (PTR) the variable in the case (PTR1) is assigned the current 
value of the union. This value (PTR1) can then be used in the executable 
code of the conformity case statement. 
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VARIANT RECORDS 

When we are defining tables for system software, we often require a record 

with some fixed information (or fields) followed by some variable 

(variant) fields. Usually, we know what all the variants look like. 
Figure 4.17 shows this pictorially. 



FIXED 
PART 

VARIANT 
PART 




RECORD 



INTEGER 



BOOLEAN 



REAL 



BOOLEAN 



INTEGER 



A 
B 



> 



i} 



SHORT 
FORM 



LONG 
FOEM 



VARIANT RECORD CONCEPT - FIGURE 4.17 

Figure 4.17 shows a record consisting of two major parts: 1) the name 
and 2) some attributes. Depending upon the type of the record the 
attributes portion of the record can be one of two forms (the short 
form or the long form) . 

In any one occurrence of the record, only one of the two forms will exist. 
However, some occurrences of the record may be the short form and others 
may be the long form. 

This kind of record structure can be declared in SWL. 

TYPE 

FORM = (SHORT, LONG), 

RECTYPE = RECORD 

NAME: STRING (11) OF CHAR 
CASE T:FORM OF 
=SHORT= A: INTEGER, 

B: BOOLEAN, 
=LONG= C: REAL, 

D: BOOLEAN, 

E: INTEGER, 
CAS END 
RECEND; 



VAR ONEREC, TWOREC : RECTYPE; 



SWL VARIANT RECORD SYNTAX - FIGURE 4.18 
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The record structure declared by the example in figure 4.18 will be one 
of the two illustrated in figure 4.19. 



NAME 
T 
A 
B 



STRING (11) OF CHAR 



SHORT 



INTEGER 



BOOLEAN 



SHORT VARIANT 



NAME 
T 
C 
D 
E 



STRING (11) OF CHAR 



LONG 



REAL 



BOOLEAN 



INTEGER 



LONG VARIANT 



VARIANT RECORD LAYOUT - FIGURE 4.19 

As illustrated in figure 4.19 there are two forms (or variants) for the 
record (LONG or SHORT). Notice that the identifier T (the tag field) 
is included in the record itself. 

How do we access or use the variant record? Consider the variable ONEREC 
declared in figure 4.18. Wg^.can sto re information into the variable one 
field at a time ._ ^ To declare which variant we are using we must assign a 
value (long or short) to the tag field T. This is illustrated for each 
record type (variant) in figure 4.20. 



"ASSUME TYPE DECLARATION" 
"AS SHOWN IN FIGURE 4.18" 

VAR ONEREC, TWOREC: RECTYPE; 



"INITIALIZE ONEREC AS SHORT RECORD" 
ONEREC. NAME := »IDENTIFIER1 ! ; 
ONEREC. T : = SHORT; 
ONEREC. A := 6; 
ONEREC. B := TRUE; 



"INITIALIZE TWOREC AS LONG RECORD" 
TWOREC. NAME := T IDENTIFIER2 ' ; 



r rW0REC. T 


:= LONG; 


TWOREC. C 


:= 6.735; 


TWOREC. D 


:= FALSE; 


TWOREC. E 


*= 5; . 



VARIANT RECORD INITIALIZATION - FIGURE 4.20 



Since the variant (Tag Field) of the record is stored in the record 
we can always determine at execution time which variant is contained 
in the record. 
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LABELS 

In the current ISWL (not SWL) language all labels must be declared with the LABEL 
statement. The label statement simply declares its constituent 
identifiers as labels. 

Labels are often required by the EXIT and CYCLE statements to identify 
which statement is being EXITed or CYCLEd. Labels are also used in the 
GOTO statement. 

A labeled statement is one that includes a label followed by a colon pre- 
ceding the statement itself. 

LABEL FORLOOP, L00P1; 



L00P1: LOOP 



LOOPEND 



L00P1 



FORLOOP: 
FOR 



FOREND; 



FORLOOP 



LABELS - FIGURE 4.21 



Notice, in figure 4.21, that the label may be placed to the left of a 
statement (as in LOOP1) or on a line by itself (as in FORLOOP), In 
either method, the label identifies the whole statement. The label 
LOOP1 refers to the entire LOOP-LOOPEND statement. A GOTO statement 
referencing L00P1 would initialize (or begin execution) at the first 
constituent statement of the LOOP statement. An EXIT statement, inside 
the FOR statement, that EXITs FORLOOP will continue execution (branch 
to) at the statement after FOREND. 



EXIT REVISITED 

The EXIT statement was discussed in Chapter 2. Recall that the EXIT 
statement exits the structured statement in which it is contained. By using 
a label with the EXIT statement it is possible to specify 
which statically encompassing structured statement is to be EXITed. 
Consider the program skeleton shown in figure 4.22. 
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WHILE A<B DO 



IF C=D 

THEN EXIT 

ELSE M SCME STATEMENTS" 
I FEND ; 



WHILEND* 



NON-LABELED EXIT - FIGURE 4.22 

In the example in figure 4.22 the EXIT statement exits the structured 
IF statement. 



Is it possible for the EXIT statement to EXIT the WHILE statement; 
that is, to cause control to be transferred to the statement after 
WHILEND? The answer is yes, using a label. See figure 4.23. 



L: WHILE A<B DO 



IF C=D 
THEN EXIT L 

ELSE "SCME STATEMENTS" 
I FEND; 



WHILEND; 

LABELED EXIT - FIGURE 4.23 

In the example in figure 4.23, when the "EXIT L" statement is executed 
control will be transferred to the statement after the one labeled L. 
This statement is of course the one after the WHILEND because label L 
designates the entire WHILE statement (from WHILE to WHILEND). 

Notice that the EXIT statement is a kind of restricted GOTO. It does 
not provide the ability to arbitrarily go anywhere in the program 
(the GOTO doesn ! t either as we will find out). The EXIT statement 
with a label allows the orderly exit from any statement (which is 
labeled) that statically (in the source code) encompasses the EXIT 
statement. 
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CYCLE STATEMENT 

The CYCLE statement allows the conditional bypassing of the statements 
inside a repetitive statement (FOR, LOOP, WHILE, REPEAT) and cycles to 
the next iteration, if any. 

The CYCLE statement may use a label to designate which repetitive 
statement is being cycled. The CYCLE statement can only cycle 
repetitive statement that statically encompass the CYCLE statement. 

The CYCLE statement can also be made conditional by using the WHEN 
clause. Examples of non-labeled CYCLE statements are given in 
figure 4.24. 

FOR I:= 1 TO 10 DO 

CYCLE WHEN 1=6; 

WRITE (I,EOL); 



FOREND; 

WHILE C/=EOL DO 

» 
IF C = A [i] THEN CYCLE; 

READ (C); 
WHILEND; 

NON-LABELED CYCLE STATEMENT - FIGURE 4.24 

In figure 4.24 the FOR statement would create 10 iterations. However, 
when the CYCLE statement is executed and 1=5 the statements from CYCLE 
to FOREND will be skipped and the next iteration (I:=7) will be done. 
The WRITE statement then would write the values of I: 1,2,3,4,5,7,8,9,10. 

'.he WHILE statement in figure 4.24 shows how the simple CYCLE statement 
can be used to cycle a repetitive statement (e.g., the WHIL3 statement). 
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LABEL L1,L2 



LI: REPEAT 



L2: WHILE 



FOR I:= 1 TO 10 DO 



CYCLE WHEN A = B [l]; 

CYCLE L2 WHEN A<B [l]; 

CYCLE LI WHEN A>B [I] 

FOREND; 
WHILEND; 
UNTIL C=EOL ; 
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LABELED CYCLE STATEMENT - FIGURE 4.25 

Figure 4.25 illustrates the use of labels in the CYCLE statement. The 
statement "CYCLE WHEN A=B [l];" will cause the FOR statement to be 
cycled when B [l} = A. The statement "CYCLE L2 WHEN A<B (l] 5 " will 
cause the WHILE statement (statement L2) to be cycled. The statement 
"CYCLE Ll WHEN A>B[TJ" will cause the REPEAT statement to be cycled. 

RETURN 

The RETURN statement will cause control to be transferred (back) to the 
procedure that called the procedure containing the return statement. 



At execution time, a return is automatically done when we reach the end 
of a procedure or function (PROCEND). For this reason we have not needed 
the return statement for our examples thus far. 

But, what if we wish to return from some place other than the end of the 
procedure or function? Then the RETURN statement is needed. The RETURN 
statement can also have (optionally) a WHEN clause making the RETURN 
statement conditional. 
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Figure 4,26 illustrates the use of the RETURN statement in a function, 

PROC CHECK (VAL M: INTEGER) BOOLEAN; 

IF M>=0 

THEN CHECK :=TRUE- 

RETURN; 
ELSE CHECK := FALSE; 
RETURN • 
IFEND; 

PROCEND CHECK; 

USE OF RETURN STATEMENT - FIGURE 4.26 

In figure 4.26, the function CHECK returns the boolean value TRUE when the 
parameter passed is positive or zero and returns the boolean value FALSE 
when the parameter passed is negative. 

GOTO STATEMENT 

The GOTO statement is not our favorite statement* In fact, we try to 
avoid writing GOTO ! s. But, if you insist - read on. 

The GOTO statement causes transfer of control to the statement designated 
by a label. 

If the label referenced is outside the current block then the form 
"GOTO EXIT label" must be used. 

ADVANCED INPUT/OUTPUT 

In Chapter 2, we discussed the simple I/O procedures READ and WRITE. These 
procedures provided the capability to read the input file and write on the 
output file. There were certain types that could be written. The input 
and output files were opened automatically at job initiation and closed 
automatically at job termination. 

Now we want to examine a more complicated world of I/O. In this environ- 
ment we must open and close files explicitly and we must ma^ipuXa^e^tim^ 
pointer to the file. We can ^ hand lg g 1 . t L hgr_fej^^i^uQJ^^ode d files. 

The I/O statements discussed here are:GET^J^ 

CLOSE, #EOF, and the file type. «**-~~~ .~~««-~- -^^ ^ 

Before we can do any advanced I/O, we must declare the filename, type of 
file, and intended use of the file. 
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TYPE 




REC 


= RECORD 




NAME : STRING (10) OF CHAR, 




DAY : 1..31, 




MONTH : 1..12, 




YEAR : 1975.. 2000, 




' INFO. : INTEGER, 




RECEND; 



VAR 

Fl [IN] ; : FILE OF CHAR, 

F2 [OUT] : FILE OF INTEGER, 

F3 [IN] ; FILE OF REC; 



FILE DECLARATIONS - FIGURE 4.27 

In Figure 4.27, we see examples of file declarations. The 

file named Fl is an input file of characters. Each GET operation will 

access one character. Character files are coded files. 

F2 and F3 are binary files. File F3 illustrates how a file of some 

arbitrary type can be declared. For file F3 each GET or PUT will access 
one record. That is, the ^ un J- t °f information^ 

t^Rs3&xx£Aj&£th.,,one I/O statement . 

The names Fl, F2 and F3 function in two capacities. First, they are the 
name of the file. Second, they are the pointers to the elements in the 
file. 

OPEN 

Before we can perform any advanced operations on a file the file must be 
explicitly opened (files INPUT and OUTPUT, however, are opened auto- 
matically). The OPEN statement opens the file specified and assigns 
the first component to the filo buffer pointer. 

An illustration of the file structure is shown in figure 4.28. 
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FILE BUFFER POINTER 




FILE 
BUFFER 



1 I 1 1 I I t 1 



Fl 



FILE OF TYPE 



VAR 
Fl [ IN ] 
X 



FILE 
REC; 



OF REC , 



OPEN (Fl); 
X:=F1a; 



FILE STRUCTURE 



FIGURE 4.28 



Figure 4.28 illustrates access to a file. The file Fl is declared to be 
a file of REC (from figure 4.27). That means each component on the file 
is a record. Notice that a variable X is also declared. The "OPEN (Fl);" 
statement opens the file Fl and positions the file buffer over the first 
component and sets the file buffer pointer to point to the file buffer. 
The statement !! X:=F1a; ,! assigns to X what the file buffer pointer points 
to (i.e. the first component in the file). In this manner, we have just 
"read" the first record from the file. 



GET STATEMENT 



To continue our reading process, we must move the file buffer to the next 
component and update the file buffer pointer accordingly. These 
operations are accomplished by the GET statement. N pfr e^tha t_GE T doe s no t r 
%££vtem^a£3* GET positXons_the file buffer and the a s £ocTa^^^T^_^rfev^ 
jDoi^er^. To jread .jj^a f w§ rj .j^y&y]i. ^sg.,,tJhe^s > yritaX T filename a • 

Now we can write a program skeleton to open a file and read the components, 
effectively transferring the components from a file to an array in memory. 

" ASSUME RECORD DECLARATION IN FIGURE 4.27" 

CONST LIMIT = 100; 

VAR Fl [IN J : FILE OF REC, 

X : ARRAY [l.. LIMIT} OF REC, 
I : [.STATIC } 1.. LIMIT +1 :=1; 

OPEN (Fl); 

WHILE NOT #EOF C F ^ AMP (K=LII1IT - ) DO 

X[l] := FU; 

I := 1+1; 
GET (Fl); 
WHILEND; 

WRITE ( ' END OF READ ' , EOL) ; 
Rev- B GET-FILE I/O - FIGURE 4.29 
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PUT STATEMENT 

The PUT s tatement appends the value of the file b uffer va ria ble (f a) to 
thefilea nd then the file buffer va riable (f,0 becomes undefined. 

For example, let f s consider writing the contents of an array of records 
onto a file for use later. 

"ASSUME RECORD DECLARATION AS IN FIG. 4.27 M 

CONST LIMIT = 100 

VAR X: ARRAY £i. .LIMIT] OF REC, 

I: 1..LIMITH, 

F2 [OUT] : FILE OF REC; 
" ASSUME ARRAY X HAS BEEN INITIALIZED" 
OPEN (F2); 

FOR I:= 1 TO LIMIT DO 
F2a := X [I]; 
PUT (F2); 
FOREND; 



PUT - FILE - Figure 4.30 

OTHER I/O STATEMENTS 

The REWIND statement is used to reset the current po sition to the begin- 
nin g of the f i le a^jdLaaslgns^the^llIe^bufler point eiT3^ ~~~ 
c^mjgoij^Tat^^^ To rewind file Fl, the statement "REWINEP(Fl) ;" 
would-be uied\ ""' — -— -*-. , 

The CLOSE statement closes the file. I/O operations are not allowed in 
the file once it has been closed. To close file Fl, the statement 
"CLOSECFi);" would be used. 

DATA-REPRESENTATION DEPENDENT FEATURES 

The facilities covered in this section can be used only in a procedure or 
function which is declared £REPDEP]. Generally, you will not need (and 
will not use) these facilities. Occasionally, you will need these features, 
and when you do they MUST be declared ptEPDEP^ . 

One facility, which is needed occasionally, is the ability to measure a 
variables storage space requirements in the addressable unit of memory for the 
machine on which the SWL program is executing. This kind of ability 
would certainly be required in a memory management utility for example. 

To support the need for assigning values to the unit of addressable 
storage, the CELL data type was created. 
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Only assignment and equality tests are defined on a CELL. 

To raanipulate cells two functions are provided: 

1) #SIZE (variable identifier) function returns the number of CELLS 
required to contain the variable identifier or type identifier specified; 

2) #LOC (argument) returns a pointer which can be assigned to any direct 
pointer • These functions, when used, must appear in a fREPDEP"] procedure 
or function. 

For example, the following function returns an integer indicating the 
number of cells required to contain the specified argument (which is 
ah array in this example). 

TYPE A =ARRAY [*] OF INTEGER 
PROC [REPDEP] MEMORY 

(VAL M:A ;) INTEGER; 
MEMORY := #SIZE (M); 
PROCEND MEMORY; 

REPDEP FUNCTION #SIZE - Figure 4.31 

The next example illustrates how values may be assigned to CELL type. 

PROC tXDCL REPDEP] MAIN; 
VAR A,C : CELL; 

P : aINTEGERj 

P:= #LOC (A) 
PA:= 0110(8); 
C := A; 



PROCEND MAIN; 
REPDEP CELL AND #L0C FUNCTION - Figure 4.32 

Many interesting things are happening in figure 4.32. 

Notice the statement "P:= #L0C (A); ,f . P is a pointer to an integer. A 
is type cell. #L0C (A) returns a pointer to type cell. This assignment 
then is quasi-legal. That is, it assigns a pointer to a cell to a variable 
that is a pointer to an integer. This is the mixing of types that requires 
the REPDEP attribute. #L0C will provide a pointer to its argument that can 
be assigned to any pointer variable. 

j! The next statement "Pa:= 0110(8); n is no surprise. It simply assigns 
yj the value 0110(8) to what JLmint.^ Unfortunately, this 

is the only way to assign constants directly to a cell. 

Once cells have been initialized, we can make assignments as shown in the 
statement !, C:=A;". Here, we are simply assigning the value of cell A to 
cell C (no type mixing here). 
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STANDARD FUNCTIONS 

We have covered most of the standard functions available in the language 

throughout the text. Below you will find a list of the current standard 
functions. 

FUNCTION REFER TO 

$REAL (X) CHAPTER 2, fig 2.11 

$INTEGER (X) CHAPTER 2, fig 2.11 

$CHAR (X) CHAPTER 2 5 fig 2.11 

$STRING (l,s,f) CHAPTER- 2 

#STRLENGTH (S) CHAPTER 4, fig 4.10 

#L0WERB0UND (array,N) CHAPTER 4, fig 4.8 

#UPPERBOUND (array ,N) CHAPTER 4, fig 4.8 

#E0F (file name) CHAPTER 2, fig 2.25 

#L0C (argument) CHAPTER 4, fig 4.32 

#SIZE (argument) CHAPTER 4, fig 4.31 
#STRINGREP (VAL,SUBSTR, WIDTH, DECIMALS) CHAPTER 2 
#SUCC (X) 
#PRED (X) 
#ABS (X) 



STANDARD FUNCTIONS - Figure 4.33 



SUCCESSOR & PREDECESSOR FUNCTIONS 

The #SUCC (argument) function returns the successor of its argument. 
For example #SUCC (3) is the value 4 because the successor of three 
is four. 

If an ordinal was declared: 

TYPE 

COLOR = (RED, YELLOW, BLUE, GREEN); 

Then #SUCC (YELLOW) would be BLUE. The #SUCC ( f A') is ! B», etc. 

The #PRED (argument) function is similar; it returns the predecessor of 
its argument. 

What happens if we request a predecessor or successor that does not 
exist (like #SUCC (GREEN) or #PRED (RED))? The result becomes 
undefined I 



4-27 



C OMPILE TIME OPTION S 1 

Compile time options are currently implemented through the mechanism 
of comment toggles. A comment toggle is a toggle that is inside a 
comment line (anywhere in the program) • 

Through the use of "comment toggles 11 , the programmer has control over 
certain aspects of the generated code and the source listing, A toggle 
is a switch associated with a particular feature (such as checking for 
zero-divide), and it may be turned on or off by means of a comment 
toggle list. A comment toggle list may appear anywhere within a comment, 
and its syntax is: 

<comment toggle list> : := $<toggle> , <toggle> 
toggle : := A<plus or minus > "assignment checking" 
X<plus or minus > "index checking" 
D^plus or minus > "zero -divide checking 11 
R<plus or minus/ "rounding arithmetic" 
T^plus or minus^ "sets all of A, X, D, and R" 
C<plus or minus ^ "list object code" 
l<plus or minus> "listing on or off" 

(lines with errors listed 
even if $L-) 
S<integer> "skip<integer> lines on 

listing" 
S "skip to new page on listing" 

K<plus or minus> "overprint SWL reserved words" 
M<integer? "terminate scan of source 

lines after column <,integer>" 
B<integer? "start scan of source lines on 

column <integer>" 
<Tplus or minus ?::=+!- 
Embedded blanks may not appear within a comment toggle list* 

So, for example, to cause overprint of SWL reserved words a comment toggle 
would be constructed: "$K+". To turn off the overprint of keywords 
later on in the program, "$K-" could be used. 

The compiler initially sets the toggles to correspond to 

"$T4-,C-,L+,K-,M72,B1" 
which implies that all run-time checking is activated; arithmetic is 
performed with rounding instructions; a source listing is produced but 
without object code listing and overprinting^ and the source lines are 
scanned from column 1 up to and including column 72. 



Compile time options described here are for ISWL only. 

An entirely different mechanism of specifying compile time options 

will be used in SWL, 
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CHAPTER 5 
STRUCTURED PROGRAMMING AND SWL 



One of the primary goals we hope to attain with the use of SWL is the 
reduction in cost of developing software products. This reduction, 
hopefully, will take place to some extent in the implementation phase 
of software development and to a greater extent in the ongoing maintenance 
phase of the software developed. 

It is hoped that a high level, block-structured language (SWL) will 
help make these dreams a reality. Our dream is software which is easy 
to understand. Hence, it will be easier to implement and easier to 
maintain and modify. In our visions, we see programs with a well- 
defined (and easy-to-understand) structure. 

It is hoped that implementors will structure both their thoughts, and 
their programs. Not much can be done to tell people how to structure 
their thoughts. With respect to programs, however, we can suggest 
ways of structuring both data and executable lines of code. 
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AN UNSTRUCTURED PROGRAM - Figure 5.1 
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A STRUCTURED PROGRAM - Figure 5.2 
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Figure 5.1 illustrates graphically a sorting procedure which was written 
in an unstructured way (in FORTRAN). Notice how the lines of control 
cross and intermingle in. this procedure. It would be difficult 
to understand this flow of: control. As you can imagine the task of 
modifying the procedure is complicated by the many different ways we 
can get to many statements. 

Contrast this unstructured flow of control with the nicely nested flow of 
control in figure 5.2. This flow of control (figure 5.2) resulted 
from a SWL program written to perform exactly the same sorting algorithm. 
Notice the elegant structure. It becomes obvious which loops are the 
outermost controlling loops. Making changes to this SWL program should 
be much easier. 

Of course, it is possible to write a structured FORTRAN program or an 
unstructured SWL program - thats not the point. The point is that you 
should be aware of the structure and strive to make your program 
structures as clear and meaningful as possible. 

This goal will be easily achieved if, when writing SWL code, you try 

to avoid the GOTO statement and concentrate on the structured statements 

including the IF, WHILE and REPEAT statements. 

One approach to help make programs clearer is to develop the programs 
in a step-by-step manner. This concept was discuss in a paper by NIKLAUS 
WIRTH entitled " PROGRAM DEVELOPMENT BY STEPWISE REFINEMENT" which 
appeared in COMMUNICATIONS of the ACM, Volume 14, Number 4, April 1971. 
The program solutions were modified to SWL by John Sutherland of 
Control Data Canada Limited. 

The program we will use to illustrate these concepts is a solution to the 
n 8-Queens problem 11 . The problem may be stated: 

Given are an 8 x 8 chessboard and 8 queens which are hostile to each 
other. Find a position (or square) for each queeti so that no queen 
may be taken by any other queen (i.e. every row, column and diagonal 
contains at most one queen). 

Our program will find one solution to the problem. In thinking about 
the problem it is clear that we will want to test a square (by considering 
a queen to be there). If the position is safe, then we will set the 
queen at that position and move on to the next column. 

If the position is not safe, we want to consider additional positions 
in the column. If we cannot find an acceptable position in a column 9 
we must go back to the preceding column and move the queen there. 

The program ends successfully if we try to move ox\ to the 9th (non- 
existant) column. This of course means that we have successfully 
placed all 8 preceding queens. 

The program ends unsuccessfully if we have to move the queen in the 
first column to the 8th rank unsuccessfully and then try the preceding 
(non-existant column). 
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So we may express our game plan at the highest level in the following 
way (figure 5.3). 

INITIALIZE; 
REPEAT 
TESTSQUARE; 
IF SAFE 
THEN SETQUEEN; 

NEXTCOLUMN; 
ELSE ADVANCEQUEEN; 
IFEND; 

UNTIL ENDOFSEARCH; 
WRITERESULT; 

PROGRAM OVERVIEW - Figure 5.3 

Our intention is reasonably clear. After some initialization, we will 
REPEAT until ENDOFSEARCH. The search algorithm entails first the test 
of a square to see if i.t can be occupied (TESTSQUARE). If the square 
is safe, then we will SETQUEEN on this square and go to the NEXTCOLUMN. 
If the square was not SAFE, then we ADVANCEQUEEN. ADVANCEQUEEN then 
must prepare for the next TESTSQUARE. We will also provide ADVANCE- 
QUEEN with enough intelligence to determine when it cannot advance in 
one column and, hence, must backtrack to a preceding column. 

Our goal is to leave the text of the program in figure 5.3 intact and 
arrange our data structure and procedures so that this high-level 
description of the program is correct. Note that this approach 
closely resembles the way we think about problems. 

With this high-level design completed, we must turn to the data structures 
to make the program work. We need to be able to identify valid and 
invalid positions for each queen. There are four components to this 
1) horizontal validity 2) verticle validity, 3) left diagonal 
validity, and 4) right diagonal validity. 

We can handle horizontal and vertical validity with one array (indexed 1 
to 8), making sure that there is only one queen in each row. We could 
call this array HORIZONTAL. HORIZON TAL[3]= FALSE indicates that the 
third row is not available for a queen (it has a queen in it). 

The right diagonals can be represented as an array (indexed 2 to 16), 
where the diagonal is found by adding the row and column. For example 
row 3, column 5 (sum=8) is in the same diagonal as row 6 column 2 
(sum=8). An array value TRUE would indicate that the corresponding 
right diagonal is available for a queen. 

The left diagonal can be represented as an array (indexed -7 ..7) where 
the diagonal is found by subtracting the row minus the column. For 
example row 3, column 6 (difference = -3) is in the same left diagonal 
as row 2 J column 5 (difference = -3). An array value TRUE would indicate 
that the corresponding left diagonal is available for a queen. 



5-5 



The position array (indexed 1 to 8) contains values indicating the row 

of the queen. For example POSITION [3.] = 7 would indicate that the third 

column contains a queen in the seventh row. ( 



Now lets examine some of the procedures. Here we step down to a lower 
level of refinement. 

INITIALIZE must set up all arrays to their initial values. 

TESTSQUARE must check to see if a queen can be placed on a given square 
(row and column). TESTSQUARE is shown in figure 5.4. 

PROC TESTSQUARE; 
SAFE := A[ROW] AND 

BptOW-COLUMN] AND 

C [ROW-COLUMN]; 
PROCEND TESTSQUARE; 

TESTSQUARE PROCEDURE - Figure 5,4 

The SETQUEEN procedure must mark rows, left diagonals, and right 
diagonals when they have been used. Also, when a position is used 
it must be saved in the position array. 
See figure 5.5 below: 

PROC SETQUEEN; 

A^OW] := FALSE; 

B[k0W-C0LUMN] := FALSE; 

C[ROW-COLUMNl := FALSE; 

POSITION [COLUMN] := ROW; 
PROCEND SETQUEEN ; 

SETQUEEN PROCEDURE - Figure 5.5 

The remaining procedures are equally simple. A complete program listing 
can be found in figure 5.6; 

The important point is that our programming language was able to implement, 
in a reasonable way, the logical expression of our problem. 



v 
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000001 


IM0DULE QUEENS; 




000063 




000063 


!VAR HORIZONTAL ' 


! ARRAY CI.. 8 3 0F BOOLEAN* 


000073 


f RDIAGN0L ! 


\ ARRAY C2..163 0F BOOLEAN, 


0001 12 


1 LDIAGN0L : 


! ARRAY C-7..73 0F BOOLEAN, 


000131 


1 POSITION i 


' ARRAY CI.. 83 0F INTEGER, 


0001 41 


! SAFE l 


B00LEAN, 


0001 42 


! ROW ! 


t 1 ..9* 


000143 


! COLUMN ! 


0. .9, 


0001 44 


' I ! 


! -7. .16J 


000145 




000145 


IPROC REM0VEQUEEN; 


000145 


REPEAT 


000150 


COLUMN := COLUMN - 1 ; 


000154 i 


IF COLUMN < 1 THEN RETURN IFEND; 


000156 


1 ROW := P0SITI0NCC0LUMN3; 


000166 ! 


HORIZONTAL CROW 3 :=TRUE; 


000173 ' 


RDIAGN0LCR0W+C0LUMN3 :=TRUE; 


000200 ! 


LDIAGN0LCR0W-C0LUMN3J=TRUE; 


000206 


ROW := ROW + 1 5 


000212 


'UNTIL ROW <= 8; 


00021 4 


PROCEND REMOVEQUEEN; 


000216 




000216 




000216 


PROC INITIALIZE? 


000216 


'FOR I := 1 T0 8 D0 


000227 


H0RIZONTALCI] := TRUE F0RENDJ 


000235 


'FOR I := 2 TO 16 D0 


000244 


1 RDIAGN0LCI3 J= TRUE F0REND; 


000252 


'FOR I := -7 TO 7 D0 


000261 


' LDIAGN0LCI3 := TRUE F0REND; 


000267 


FOR I := 1 TO 8 D0 


000276 i 


POSITIONCII := F0RENDJ 


000304 ! 


C0LUMN:=1 J 


000305 ! 


ROW : = l ; 


000306 < 


PROCEND INITIALIZE? 


. 000310 ' 




000310 ! 


PROC WRITERESULT; 


000310 ! 


IF COLUMN < 1 


000313 < 


1 THEN WRITEC NO MORE SOLUTIONS '> E0L ) i 


000331 ! 


RETURN IFEND; 


000332 


FOR ROW := 1 T0 8 DO 


0003*1 


WRITE(P0SITI0NCR0W3 :5) 5 


000346 ! 


F0RENOI 


000350 ! 


WRITECEOL) i 


000354 ! 


PR0CEND WRITERESULT? 


000356 ! 





000356 ! 




000356 ! 


PROC TESTSQUARE; 


000356 ! 


SAFE := H0RIZ0NTALCR0W3 AND 


000365 ! 


RDIAGN0LCR0W+C0LUMN3 AND 


000372 ! 


LDIAGN0LCR0W-C0LUMN3 ; 


000402 ! 


PR0CEND TESTSQUARE; 



STEPWISE REFINEMENT - Figure 5.6 
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000404 
000404 

000404 

000413 

J10Q42Q 



PR0C SET9UEEN; 

H0RIZ0NTALCR0W3 : = FALSE? 
RDIAGN0LCR0W+C0LUMN3 := FALSE; 
LDIAGN0LCR0W-C0LUMN3 ;= FALSE; 



000425 
000432 
000434 
000434 
000434 
000442 



P0SITI0NCC0LUMN3 
PR0CEND SETQUEENJ 



:= R0WJ 



PR0C NEXTC0LUMN; 
COLUMN := COLUMN + 1 J 
ROW ;= 1; 



000443 
000445 
000445 
000445 
000454 
000457 



PR0CEND NEXTC0LUMN; 

PR0C ADVANCEQUEEN; 

ROW := ROW + 1 t 

IF ROW > 8 THEN REM0VEQUEEN; 
PR0CEND ADVANCEQUEEN; 



IFENDJ 



000461 
000461 
000461 
000473 
000475 
000475 



PR0C END0FSEARCH BOOLEAN; 

END0FSEARCH: = (C0LUMN<1 > 0R (C0LUMN>8); 
PR0CEND END0FSEARCHJ 

PR0C QXDCL3 MAIN; 



000475 
000501 
000501 
000502 
000502 
000504 



INITIALIZE; 
REPEAT 

TESTSQUARE; 

IF SAFE 
THEN SETQUEEN; 
NEXTC0LUMN; 



000505 
000507 
000507 
00051 1 
000512 
00051 4 



ELSE ADVANCEQUEEN; 
IFEND; 

until end0fsearch (); 
writeresult; 
pr0cend maini 
m0dend queens; 



STEPWISE REFINEMENT - Figure 5.6 (Continued) 



To find the complete list of solutions to this problem (all 92 of them) 
we need only cause the repeat sequence of procedure MAIN to be repeated 
as shown in figure 5.7. 



000477 
000477 
000503 
000503 
000503 
000504 



!PR0C CXDCL1 
! INITIALIZE* 
IREPEAT 
REPEAT 
TESTSQUAREl 
IF SAFE 



MAIN* 



000504 
000506 
000507 
00051 1 
00051 1 
000513 



THEN SETQUEEN; 

NEXTC0LUMNJ 
ELSE ADVANCEQUEEN* 
IFENDi 
UNTIL END0FSEARCH ()t 
WRITERESULTJ 



000514 
000517 
000521 



IF C0LUMN > = 1 THEN ADVANCEQUEEN IFENDi 
UNTIL C0LUMN < 1 I 
PR0CEND MAIN! 



MODIFICATION TO PROGRAM OF FIGURE 5.6 - Figure 5.7 



5-« 



CHAPTER 6 

SWL PROGRAMMING TECHNIQUES AND CONVENTIONS 

This chapter is an assembly of techniques and conventions that may be 
used at your discretion. Unfortunately, at this time there are no 
conventions. There are also precious few good programming techniques < 
It is hoped that readers will provide some feedback and suggest 
additional SWL Programming TECHNIQUES. 
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TECHNIQUES FOR EASE OF MAINTENANCE 

Almost every program declares some variables. Typically, at some later 
date, it becomes necessary to add variables to the program. Consider 
the variable declaration of figure 6.1 



VAR R: REAL, 

A: ARRAY [l..lO] OF BOOLEAN, 
C: CHAR; 



DIFFICULT TO MAINTAIN VAR DECLARATION - Figure 6.1 



In figure 6.1, if we needed (for maintenance or modification) to add 
another variable to the declaration (presumably at the end of the list 
of variables, we would have to change two lines. First, the semi-colon 
must be changed to a comma. Second, the new variable line must be 
added. The result is two modifications. Similar problems occur if 
we needed to delete the variable R or C from the declaration. 

Now refer to the variable declaration of figure 6.2. 



VAR 

R: REAL, 

A: ARRAY [1..10] OF BOOLEAN. 

C: CHAR, 



EASY TO MAINTAIN VAR DECLARATION - Figure 6.2 

In figure 6.2 5 it is easy to add a new variable with only one modification. 
Similarly, dele ting any variable from the list requires only one 
modification. This feature is not available in the current version 
of ISUL- Future versions willi howevern support this feature. 

TECHNIQUES FOR PROGRAM CLARITY 

Often, poor programming habits will cause a decrease in program clarity. 
One example of this is the unnecessary use of control statements 
(GOTO, EXIT, etc.). 

Figure 6.3 illustrates two programs. The results are identical, only the 
source code is different. The programs check for an empty line (from 
a terminal). If the line is empty, a REWIND is executed and another 
attempt is made to find data on the line. When reading data, it is 
necessary to check for end-of-file after each read. 
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LABEL 

VAR 
SUM 
N 



INTEGER, 
INTEGER, 



£ 



"CHECK FOR EOF" 
Z: IF #EOF (INPUT) 

THEN REWIND (INPUT); 
GOTO Z 
IFEND; 

n SUM UP DATA" 

SUM :=0; 
frLOOP 

READ (N); 
-EXIT WHEN #EOF (INPUT); 
SUM := SUM+N 
I — LOOPEND; 



VAR 

SUM : INTEGER, 
N : INTEGER, 

"CHECK FOR EOF" 
rfrWHILE #EOF (INPUT) DO 

REWIND (INPUT); 
L-WHILEND; 



"SUM UP DATA" 
SUM :=0; 
READ (N); 

r WHILE NOT #EOF (INPUT) DO 
SUM := SUM4-N 
READ (N); 
WHILEND- 



PROGRAM CLARITY - Figure 6,3 



In figure 6.3 both examples appear similar. However, upon detailed 
analysis the left program requires the reader to trace lines of control 
created by the GOTO and EXIT statement. The right example can be read 
more easily from top to bottom. 
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CHAPTER 7 
PERFORMANCE MEASUREMENT & PREDICTION 



In this chapter, we will be discussing techniques for improving the 
execution time performance of your SWL programs. Since the performance 
tools we will be discussing exist on the CDC CYBER 70/170 computer 
systems under the KR0N0S 2.1 operating system, the techniques are 
necessarily machine dependent. However, it is most likely that some 
similar tools will exist on future computer systems. Once you see how 
easy the tools are to use and how much information can be obtained from 
a performance study 5 you will certainly want to include performance 
testing in your software development plans. 
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PERFORMANCE PREDICTION 

Performance prediction is done prior to coding - often during the design 
stage(s) of software development. In performance prediction,we ask 
questions^ such as: 

1. Which data structure will provide most rapid access 
(least CPU time)? 

2. Which algorithm will execute in the least amount of 
CPU time? 

3. What disc loading will this program create during 
execution? 

Notice that performance prediction tries to answer questions about what 
will happen when the software is written. Performance predicition 
helps us choose the best methods of software design and implementation 
prior to coding. 

Unfortunately, at this time there exists almost no performance prediction 
information for SWL, so we must leave this important performance area 
without providing any acceptable answers. We mention the topic of 
performance prediction to indicate the lack of information and to put 
performance measurement in its proper perspective. 



PE RFORMANCE MEASUREMENT 

Performance measurement is done after a program is written. The perform- 
ance measurement tools will enable us to find the specific statements in 
our SWL program that account for the greatest percent (or amount) of CPU 
time. Armed with this information we can make modifications to our soft- 
ware to make it perform faster. In addition, after making some changes we 
can determine just what improvement in execution time was actually 
realized. In all these endeavours, however, the performance considerations 
are done after the software has been written. 

Fortunately, we have available some very good performance measurement tools. 
These are standard tools available to any program (FORTRAN, APL, COBOL, etc.) 
that runs under KRONOS 2.1 on the CDC CYBER 70/170 computer systems. These 
tools have been interfaced with SWL to make them easy to use. 



HOW DOES PERFORMANCE MEASUREMENT WORK? 



The following discussion explains the performance measurement tools on 
the CDC CYBER 70/170 computer systems. 

There are two distinct parts to our performance measurement tool. The 
first part gathers information (statistically) from the running SWL program. 



This data gathering is done at a frequency of once every 100 micro 
secondSo The data gathering is done by a Peripheral Processing Unit 
(PPU) running a data collection program called SMP! SMP reads the 
central processor P register each 100 x 10"^ seconds, categorizes the 
location of the P register (was the P register running our program or 
someone elses program?), and adds a count to the appropriate location 
in a table in the PPU f s memory. At job termination, the PPU writes the 
raw data (table contents) onto a file named PSAMPLE. This concludes the 
data gathering portion of our performance measurement tool. 

The second part of our performance tool is the data reduction program,. 
This is a standard (KR0N0S supplied) FORTRAN program (named PSAMP) that 
reads the contents of the file named PSAMPLE and produces some nice 
looking data for our interpretation. This concludes the data reduction 
portion of performance measurement. 

Now, our work begins. We correlate the performance information produced 

by the FORTRAN program (PSMP) with our SWL source language listing. From 

this correlation, we can determine how much time each SWL statement 

(or group of statements) requires. We can also determine how much time 

is spent waiting for I/O and how much time is being spent in the system 

routines. 

We may in fact, run the performance measurement tool a number of times. 
First we will be looking for an overview at the procedure level. We 
will be trying to answer the question: "which procedures require enough 
CPU time to warrant further investigation?' 1 . Then we may narrow the 
range of our performance measurement to a single procedure (or part of 
a procedure) to answer the question: "which SWL statements in this 
procedure take up most of the CPU time?". 

SYSTEM DESCRIPTION 

Figure 7.1 illustrates the important pieces of a performance measurement 
run. Your program resides in a portion of real memory. When a performance 
run is in progress your job cannot be rolled out. Xhi,s^mp^jL^.JLJ!Lba,£.^_. 
performance measurement^ JDHJS can only J^e j gadg,. Jrg,,, the bg^ckgrpjin^Xsi^ 
"Da^ch^moS^r" There are two ways to run batch jobs:TT) read the job in 
fromTEHe CARD reader, or 2) use the SUMIT command from the terminal. 
The only restriction is that the performance measurement job may not run 
interactively from the terminal. As your job is running the dedicated 
PPU (SMP) is sampling the P register every 100 micro seconds and updating 
the PPU raw data table. At job termination the file PSAMPLE is created. 

The PPU raw data table is 202 ft entries long. One entry is for all samples 
found below the range you have asked to sample. A second entry is devoted 
to all samples above the range you have asked to see. The remaining 200 
entries are for the range you have asked to examine. 
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CYBER 
CPU 



P -REGISTER 



PPU-SMP 











DAT* 

TA8U 












DISC FILE 



FL-1 



YOUR 
PROGRAM 



REAL MEMORY 



PERFORMANCE MEASUREMENT SYSTEM DESCRIPTION - Figure 7.1 
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If, for example, you ask to examine the 200 word area in your program from 
11306~ to 11505o then the raw data table will have one entry for each word 
in your program in the range you wanted sampled • 

Remember that the PPU raw data table is fixed in length (200g entries). 
So, if you ask for a sample range of 300 words (say from 16214g to 16513 ) 
then the PPU raw data table will use one entry to represent two words 
from your program. Hence the resolution of the sample will be (every) two 
words. 

Figure 7.2 shows the correspondence between the range you ask to sample 
and the resolution of the data produced. 

SAMPLE RAW 

RANGE DATA 

REQUESTED TABLE 

(R) RESOLUTION 

0<R^200 g 1 WORD 

201g^R^400 8 2 WORDS 

401 8 ^R^1000 8 4 WORDS 

1001 8 ^R^2000 8 10 8 WORDS 

2001 8 ^R^4000 g 20 WORDS 

4001 8 *=R^10000 8 40g WORDS 

10001 8 ^R^20000 100g WORDS 

20001g^R^40000g 200g WORDS 

40001g^R^100000 8 400 WORDS 

100001g^R^200000g 1000° WORDS 



SAMPLE RANGE vs RESOLUTION - Figure 7.2 



SWL INTERFACE 

The interface function is written in assembly language (COMPASS) to conform 
to and be callable from any SWL procedure. The interface procedure accepts 
two paramaters (FIRSTword address to be sampled and LASTword address to be 
sampled) and returns a boolean result. The boolean result is always TRUE 
on the CDC CYBER computer system. It would be FALSE on a computer system 
that did not have the performance measurement tools. The CCMPASS interface 
procedure calls the PPU program SMP and insures that only one performance 
measurment is allowed to run. This interlock (allowing only one sampling 
run) is done to insure that the computer system resources (central memory 
and Peripheral Processors) are not all tied up doing sampling runs. 
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The COMPASS interface function is equivalent to the following SWL 

procedure declaration: 

/ 

PROC [XDCL] SWLSMP (VAL FWA,LWA: INTEGER) BOOLEAN; 

PROCEND SWLSMP; 

So, when you want to do a sampling run you must declare SWLSMP to be 
XREF as follows: 

PROC [XREF] SWLSMP (VAL FWA,LWA: INTEGER) BOOLEAN; 

Then, when you want to begin the sampling run the SWLSMP function is 
called giving the FWA and LWA to be sampled. A typical calling sequence 
might be: 

IF SWLSMP (500(8), 1627(8)) 

THEN WRITE (» SWLSMP OUTPUT FOLLOWS ' ,E0L) ; 

ELSE WRITE (' SWLSMP NOT AVAILABLE T ,E0L) ; 
IFEND; 

The COMPASS interface function (SWLSMP) is available in source form and 
may be obtained with the command: 

GET, SWLSMP/UN=ZED 

SWLSMP is also reproduced in figure 7.3. Since this is not a guide for 
CCMPASS programmers SWLSMP will not be explained in detail. 
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luENf SW'LSMP 
ENTRY SWLSMP 



* WRITTEN BY 5 RON ROTHSTEIN * 

* CDC F AClL If Y : ft OF AC *" 

* COMPOSED ON : 25 OCTObER 1974 « 
-::- LAST MODIFIED: 28 OCTObER 1^74 * 



iSWL EQUIVALENT STATEMENT: 



PROC [xDCLl SWLSMP 

(VAL FwAiLWA: INTEGER) BOOLEAN? 



# 
& 
& 
& 
& 
«* 



*####&*&#&&####&##&##&###&#&#&##*&'*#&&##&#&&#& 



SWLb^P 



S*() 
L*0 

BX7 

SbS_ 

SA7 

Sb6 



B5 

X7 + X0 

66 

B5 + 1 
B6 + 6 



* ENTRY SEQUENCE 



Sb2 XXXXXX+10 

SA2 80*62 

MXO 42D __ 

"dA2" ~X2*XT0 

SX3 BO^ERAD 

B/6 X2 + X3 

S*6 B0 + b2 



# « •&>'«'** « '<* * * *# * * * * 

* initialize fet 

■* ERROR RETURN ADDR 

"*~50 PSAMPCE BUSY 

♦.MESSAGE WILL NOT 

» APPEAR IN DAYFlLE 



aTTCH 



BSS 









ATTACH 


xxxxxx»» »«w 






SA1 


xxxxxx 


read return code 




MxQ 


8 


CONSTRUCT MASK 




LXO 


IB 


POSITION TO BITS 17-10 




BAl 


.X0«X1 


EXTRACT CODE BITS 




SJl 


XI 


MOVE CODE TO 81 




S»2 


4000b 


PSMPLE FILE 




Nt 


B1»B^,nEXT 


not found 



S*6 BO 
SA6 B5 + 2 
MESSAGE MESS1»3»R 



psample := FALSE. 
PSAMPLE FILE NOT FOUND 



Eu 



B0*B0»EXlT RETURN 



\'tXT 



Sb2 2000b PSAMPLE FILE 

Nt B1*B2»NEXT1 FOUND BUSY 

RECALL 

EQ B0«B0,ATTCH TRY AGAIN LATER 



SWLSMP INTERFACE FUNCTION - Figure 7.3 
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•vtxri 


E'J 


BltBO.CALSMP 


OTHER ERRORS 




SX6 


BO 






SA6 


B5*2 


psAmple := false; 




MESSAGE MtbS3*3»R 


ERRORS ON PSAMPLE FILE 




EO 


B0»B0»EXIT 


RETURN 


CALSMP 


SA1 


B5*3 


GET FWA 




SA2 

SXb 


BS*<+ 


GET LWA 




2315208 


+ SMP+ 




LX6 


42 D 


LEFT JUSTIFY *SMP+ 




MXO 


42U 


77777777777777000000 




dxi 


-X0»X1 


0..0FWA 




BX2 


-X0*X2 


0..0LWA 




Lxl 


180 


0..0FWA0..0 




1X6 


X6 + X1 


SMP.FWA0..0 




BX6 


X6 + X2 


SMP-EWA.LWA 




MAl 


1 






LU 


41D 


RECALL BIT 




1X6 


X6+X1 


SMP.R.FWA.LWA 




RJ 


=XSYS= 






SX6 


60*1/ 


TRUE 




SA6 


B5*2 


PSAMPLE := TRUE; 


t A I T 


SA1 


B5 + 1 


«• « •tnnnnnnnnnnn* # •» 




5a6 
Sb7 


BS 


ft 




XI 


* EXIT SEQUENCt 




LX1 


421) 


■» 




SrtS 


XI 


» 




JP 


«7 


■»» ■&#»•»•&«•*»•»«•<**»*■ 


ERAU 


BSS 
DiS 


4 




mE'SSI 


f*PSAMPLt FILE NOT FOUND* 


w£SS3 


D1S 


♦^ERRORS ON 


PSAMPLE FILE* 


I.EN 


t'JU 


103B 


•«■«■«*#»#<»«■»•»*»«•#•» 


XXXXXX 


FlLtB 


BUF»LEN,FET= 


:l4,EPRtPFN=PSAMPLE,USN=7ED 


HUF 


BSS 


LEN 


»#««**»««#*##»»» 



"End 



s^usmf 



SWLSMP INTERFACE FUNCTION - Figure 7.3 (Continued) 



GETTING STARTED 

Assuming that you want to initiate your sample run from your terminal, 

you must create a SUBMIT file and give that file a name. The SUBMIT 
file should contain the following (the numbers on the left are not in 

the SUBMIT file they are for reference only). 

1. XYZ,CM10000,T100. YOUR NAME 

2. ACCOUNT, XYZ, PASSWORD . 

3. CHARGE , CHARGENO , PRO JEC TIP . 

4. ATTACH ,ISWL/UN=ALL. 

5 . GE T , I SWLLI B /UN=ALL . 

6. GET,UTL/UN=ALL. 

7 . GET , SWLSMP/UN=ZED . 

8. GET,YOURPROG. 

9. GET,YOURDATA. 

10. RFL, 70000. 

11. CCMPASS,I=SWLSMP,0=Z,B=LGO. 

12. RFL, 112000. 

1 3 . ISWL , I =YOURPROG , 0=Z , B=LG0 . 

14. MAP, ON. 

15. LGO,I=YOURDATA.,0=Z. 

16. PSAMP (,A). 

17. REWIND ,A. 

18. COPYCR,A,Z. 

19. REWIND, OUTPUT. 

20. C0PYCR, OUTPUT, Z. 

21. CTIME. 

22. DAYFILE, Z. 

23 . UTL , 1000 , INP=Z , 0UTP=LIST . 

24. DISPOSE, LIST>=PR/EI=XYZ. 
2 5. DAYFILE , LOOKSEE . 

2 6. REPLACE, LOOKSEE. 

2 7. EXIT. 

28. DAYFILE, LOOKSEE. 

29 . REPLACE , LOOKSEE . 



SUMIT FILE FOR SAMPLING - FIGURE 7.4 



In the example, SUMIT file in figure 7.4 the only things you need to change 
are those that are underlined. These include your user number (lines 1,2, 
and 24), your password (line 2), your charge information (line 3), the name 
of the file containing your program (lines 8 and 13), and the name of the 
file containing your data (lines 9 and 15). All the other lines may be 
used exactly as shown. 

Lines 25 thru 29 produce a copy of the SUBMIT dayfile at your terminal. 
With this file (LOOKSEE) available you can examine the dayfile to be 
sure that all went well. The output listings will be available when 
you log-in to an Export/Import terminal (20OUT). If you want the output 
to be somewhere else, simply change line 24 accordingly. 
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THE LOAD MAP 

The load map will enable you to get a picture of where things are in the 
field length (memory) when your program is running. 

Figure 7.5 is the load map from our sample program (to be discussed later). 

Figure 7.6 shows how we can interpret the load map to gain a picture of 
where. each module is loaded. This is necessary in order to correctly 
analyse the sample data. 
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LOAD MAP. 



FL REQUIRED TO LOAD 13400 
FL REQUIRED TO RUN 6400 
INITIAL TRANSFER TO SWLSY.i 



^055 



BLOCK ASSIGNMENTS. 



BLOCK 


ADDRESS 


LENGTH 


FILE 


SwLSMP 


101 


171 


LGO 


/GETPUT/ 


272 


200 




LUOPS 


472 


164 


LGO 


SWLSYS 


656 


3350 


ISWLLIB 


CPOPFM 


4226 


10 


SYSLIB 


CPUSYS 


4236 


3t 


SYSLIB 


// 


4270 


2002 





fcNTRY POINTS, 


» 








ENTRY 


ADDRESS 


REFERENCES 






SWLSMP 










SWLSMP 


101 


LOOPS 


564 




LOOPS 








MAIN 


555 


SWLSYS • 


M42 




SWLSYS 










SWLSY.I 


405B 








RPVTAd 


4151 








CPUPFM 










PFM = 


4227 


• SWLSMP 


111 




CPUSYS 










SYS = 


4241 


SWLSMP 
CPUPFM 


133 
*226 




RCL = 


4253 


SWLSMP 


121 




iVNB = 


4260 


CPUPI- M 


*231 




MS6 = 


4265 


SWLSMP 


116 


125 



TYPICAL LOAD "MAP - Figure 7.5 
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100 


KRONOS SYSTEM AREA 


101 
271 


SWLSMP INTERFACE FUNCTION 


272 

471 


/GET PUT/ COMMON I/O AREA 


472 
655 


LOOPS 

(THIS WILL BE YOUR PROGRAM) 


656 
4225 


SWLSYS 

SWL SYSTEM ROUTINES 


4226 
4235 


CPUPEM 

CPU PERMANENT FILE MANAGER 


4236 
4267 


CPUSYS 

CPU SYSTEM MANAGER 


4270 


BLANK COMMON 



MEMORY LAYOUT DERIVED FRCM LOADER MAP - Figure 7.6 
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From the load map (fig. 7.5) or from the memory layout (fig. 7.6) we can 
see that our program "LOOPS 11 begins at location 472g. This number (472g) 
is called the (LOADER) program offset. It represents the offset from the 
start of the field length to the start of our program. This information 
is essential and only available from the loader map. 

THE PROGRAM MEASURED 

This will be your program, of course, but for this illustration we will 

supply a program that contains four SWL methods of accomplishing a 

repetitive loop with control variable. The four methods use: 

FOR, REPEAT, WHILE; and LOOP statements respectively. We will attempt to 

determine which method is the fastest and how much faster it is. 

Figure 7.7 is a listing of the source program. 
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00 000] vM(V*ULE LOOPS* 

o o o o 6 3 v 

000061 vPPOC fXPFF] S^SMP (VAL M,N : INTEGER >.' BOOLEAN* 

O0 0A3 v 

oooo63 vppoc [xncLl hatn; 

00 006 } v 

000063 vLA^FL Ll ♦L?«L3*L4; 



000 

ooo 
o o o 


00 
00 
00 
o 
000 

o 


OOO 
00 o 
00 
O 

ooo 
00 
ooo 

1 

ooo 



o 

00 
000 
o 
0-0 
000 

noo 
00^ 
00 



61 vCO (ST LOOPCOUMT = 1000001 

6 3 v\/A^ T : T N ! jFr-,P"t5 : • 

6 3 v 

63 vTF SWLS'IP ( + 47? ( 8 ) #162 ( 8 ) + 47? ( 8 ) ) 

7 '? v "t H F \| ' W p I J F. ( * S ^ L S M P 6" "0 T P f F OL L W S * # E L ) ; 

1? v FL.SE WPI"TF(* SWLSMp NOT" AVAILABLE *«EOL); 

1] vTFrMn; 

3 1 v 

31 ■ vLltm* T := 1 TO LOOP-COUNT' 00 

3S v * r np i. nop* 

~>o v FOPp.MO 5 

4 vL.p • T :=n * 

a] v . qfofAT 

a ] v t : = t * ] : 

4 3 v ^Oppp A j i nosii 

6 3 v UNTTL T >= LOOPCOUNT; 

4S v 

4s vli:t:=o; 

a^ v VHJLF T <=. LOOPCOUNT 00 

s o v T : = T ♦ 1 ? 

S? v /*JH I LF L' v ">£>* 

S? v WHTLENO:' 

S^ v 

S3 v|_4t t :=o ; 

^4 v LOOP 

64 v T I =1 ♦] 5 

S6 v ^LOOP LOOP* 

Sb v ^vjt when t >= lOOPCOUNT* 

6 1 v i.no^ r Mn? 

6? v 

ts? vPRoCFMO MAIM; 

(C4 V M0 )FNO loops; . ■ ' 



SOURCE PROGRAM TO BE SAMPLED - Figure 7.7 
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In figure 7.7 we have a sample program. The actual numbers on the left 
of the listing represent the offset (in words, OCTAL) of each statement 
from the beginning of the module. Each of the repetitive statements is 
labeled (L1,L2,L3 and L4) . This insures that the statement will begin 
on a new word. We can see that the FOR statement (LI) begins at 
location 131 g and continues until 137g. The repeat statement (L2) 
begins at 140g. 

From the Loader Map we can see that the loader has loaded this module 
(LOOPS) beginning at 472 g . Hence the actual location of the FOR 
statement is 131 Q to 137g plus 472 g or 623 g to 631 . 

Figure 7.8 illustrates the computations required to find the actual 
locations of each of the repetitive statements. 



1. BELOW FOR STATEMENT: 
+ LOADER OFFSET 
ACTUAL ADDRESSES 



On TO 130 Q 
472 8 TO 622 8 



2. FOR STATEMENT: 
+ LOADER OFFSET 
ACTUAL ADDRESSES 



131 8 TO 137g 



472 £ 



472 , 



623g TO 631g 



3. REPEAT STATEMENT: 
+ LOADER OFFSET 
ACTUAL ADDRESSES 



140 8 TO 144, 
472 8 472! 

632~3" TO 63T 



8 



4. WHILE STATEMENT: 
+ LOADER OFFSET 
ACTUAL ADDRESSES 



5. LOOP STATEMENT: 
+ LOADER OFFSET 
ACTUAL ADDRESSES 



145 8 TO 152 8 



472, 



472 



a 



63 7 8 TO 644g 
153 8 TO 162g 



472 8 472g 
355g~ TO '6~55 8 " 



6. ABOVE LOOP STATEMENT 



655g TO END 



ACTUAL ADDRESS COMPUTATION - Figure 7.8 



7-15 



ANALYZING THE RESULTS 

The results of a sample run come in two parts. The first part is shown 
in figure 7.9 below. 



p pfgiSTF^ SAMPLES FOP 1.60*0 = 7. 
7-/03/10. 0«.-*0 # S9.. 

P| APSFH P£AL TT M F 10 # *S4S SFC # 

Fl v\PSFO CPU TTMF 4 # 059 SFC. 

S*^PLF RAN^F ** FROM 00047? TO 000*7^ 

Saw^lpS JO^ m^T ACTIVE V^^S 

S^^plfS JOR TM *FCALL 447 

c; :-, mplps R F I . O W ^ a N G F ' 

Sa.mplFS !M PaNJGF IMP'JS 

S^MPLrS AROVF PANGF 1^5 

q.v*PLFS CPU AT SUR-CP 







TOTAL SAMP! fc, 1040^?' 



SAMPLE OUTPUT - 1st PART - FIGURE 7.9 

In the output shown in figure 7.9 the first line "P REGISTER SAMPLES 
FOR LGO,0=Z." indicates that all the information to follow is for the 
LGO statement only. This is the KRONOS control statement that caused 
our program (LOOPS) to begin execution. The samples are all done in 
the time between the invocation of SMP (By the statement IF SWLSMP 
(...)) until the "PR0CEND MAIN;" statement in our program (LOOP). 

The next line simply contains the date and time of this sample run. 

The next two lines report the total real time and CPU tine used while 
sampling took place. 

The "SAMPLE RANGE" is given next as a check on the parameters (FWA & 
LWA) supplied in the call to function SWLSMP. Remember that the LWA 
will be rounded up to the next power of two interval (see fig. 7.2), 

The remaining lines describe the results of the sampling (which occurs 
approximately once each 100x10-6 seconds). 

The "SAMPLES JOB NOT ACTIVE" is the number of samples when the CPU was 
running some other job. During these samples real time is going by 
but there is no CPU time for our job. 

n SAMPLES JOB IN RECALL" is the number of samples when our job was found 
to be in recall. This time usually represents I/O and system requests 
made by our job. 

"SAMPLES BELOW RANGE" are the samples when the CPU was running our job 
but the P register was found below the range being sampled. 
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"SAMPLES IN RANGE" are the samples when the CPU was running our job and 
the P register was found to be within the range we have asked to sample. 

"SAMPLES ABOVE RANGE" are the samples when the CPU was running our job, 
but the P register was found to be above the range being sampled, 

"SAMPLES CPU AT SUB-CP" are the samples when the CPU was found at a sub- 
control point. These will always be zero unless we are sampling a 
KRQNOS SUBSYSTEM (like TELEX, etc.). 

"TOTAL SAMPLES" is just the sum of all the other reported samples. 

Since the sampling rate is pretty close to one sample, each 100x10" 
:an convert 
samples by 



second we can convert any sample count into time by multiplying the 
number of samples by 10 "^ ( 100x10"° sec = 10"* sec). 



So, for example, the "TOTAL SAMPLES" is 104062. In terms of time, this is 
10.4062 seconds. The "ELAPSED REAL TIME" was reported to be 10.645 
seconds. The total samples should (in terms of time) equal the real 
time. Does 10.4062 equal 10.645? Nol The error, however, is 0.2388 
seconds or an error of (((10.645 - 10. 4062) /10. 645)*100 = 2.24%) 
2.24 percent. 

We could of course compute the sampling rate: 

REAL TIME = 10.645 = 102 x 10~ 6 sec/sample 
TOTAL SAMPLES 104062 

But the result is so close to 100x10"° seconds that we will generally 
use the nominal sampling rate of 100x10"" sec/sample. 

The sum of SAMPLES BELOW RANGE + SAMPLES IN RANGE + SAMPLES ABOVE RANGE 
will equal the ELAPSED CPU TIME (with a small percent error). 

From the above information we can answer questions like: 

1. What percent (or how much) real-time was spent outside 
our job (i.e. waiting on other jobs)? 

2. What percent (or how much) real-time was spent waiting 
for our job to complete I/O & SYSTEM operations? 

3. What percent (or how much) CPU time was spent in the 
range we are sampling? 

4. Is our job I/O bound or CPU bound? What percent of the real 
time is I/O? What percent of the real time is CPU time? 

There are, perhaps, many other questions we could ask. The above is 
just a sample of the kinds of information to be obtained from the 
first part of the output of a performance measurement run. 
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Figure 7.10 shows the second part of the sample output. This part is a 
detailed account of where the P register was found for samples ABOVE 
RANGE, IN RANGE, and BELOW RANGE. 

The leftmost column is the P-register locations sampled. The next 
column is the number of samples (count) at each P-register location. 
The next column (PCT) is the percent of the CPU time that the count 
represents. Then we have a bunch of asterisks(*) • Each asterisk 
represents 1 percent. So the number of asterisks is a bar-chart (or 
histogram) representation of the percent (PCT) column. The plus signs 
(+), when connected, form an accumulation of CPU time. Notice the 
numbers to 9, along the top margin. These represent percent of 
CPU TIME accumulated. So after connecting the plus signs together 
we can make statements like: "By the time location 633g is reached 
28 percent of the CPU time has been used". This kind of comment is 
only really meaningful for a program that progresses from top to bottom 
without a lot of jumps (or GOTO's) from one end of the program to the 
other. 
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P-REG 



COUNT PCT 



PKI o*/ 





0.0 


OO047? 





0.0 


00047^ 





0,0 


000474 





0.0 


00047^ 





0.0 


00O476 





0.0 



F 
o 
ft 






O00*?4 
00*?5 

000*?* 
ooo*?7 
n n * 1 



UJ 

H 

I 

L 

€ 



L 



? 



000*7? 

000*?1 
00 0*14 

ooo*tr 
^000 * 1 * 

0*40 
0*41 
00 0*4? 
000*4? 
000 *6.4 
*4.q" 
000*4* 
000*47 
ooo*so 
ooo*«=;] 
_q 0* s ? 

00O*q4 



^ s S 

ooo*q* 

000*^7 

00 *. * q 
"0 on**f 
000**? 
000**3 
000**4 
ooo** 1 :; 
* * * 
"000**7 

000*70 

000*71 
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In figure 7.10 the locations of each statement (FOR, REPEAT, WHILE, LOOP) 
are identified. By adding up the percentages we can determine how much 
(or what percent of) GPU time is spent on each statement. This infor- 
mation is summarized in figure 7.11. 



1. 


BELOW 


472 8 TO 622 g 


0.0% 


2. 


FOR STATEMENT 


623 8 TO 631 8 


21.7% 


3. 


REPEAT STATEMENT 


632 8 TO 636 g 


22.17o 


4. 


WHILE STATEMENT 


637 8 TO 644 g 


25.7% 


5. 


LOOP STATEMENT 


645 8 TO 654g 


26.07. 


6. 


ABOVE 


655 8 TO END 


4.27o 




TOTAL 




99.77, 



REPETITIVE STATEMENT RESULTS - FIGURE 7.11 

As shown in figure 7.11 there isn ! t much difference between these 
repetitive statements, considering our 3% error factor. However, the 
fastest repetitive statement is the FOR (using 21.7% of the CPU TIME). 
The slowest repetitive statement is the LOOP statement (using 26.0% of 
the CPU TIME). 

So there is a difference in repetitive statements - but not much. 
IMPROVING PERFORMANCE 

The techniques shown above can be used to determine how much CPU time is 
being spent in each Procedure in your program. 

This can lead you quickly to examine the few procedures that are taking 
most of the CPU time. Experience has shown that most of the CPU time is 
generally spent in one or two of the many procedures in a software system. 

While each program is unique there are generally two ways of improving the 
performance of a program. One method is to fix up the executable code. 
This can be done using a different algorithm or eliminating redundant 
execution statements. 

The other method for improving performance is to change the data 
structures and of course thereby change the access to the data structure. 
In many procedures significant amounts of CPU time are wasted thru 
inefficient accessing of data structures. 

SUMMARY 

With the tools and concepts presented here you can do a reasonably complete 
performance measurement study. You ^ill be able to speed up your programs. 
The amount of speed up, of course, is difficult to say. The few software ( 
products analyzed thru performance measurement so far have been improved 
anywhere from 50 to 400 percent. 

Sometimes many modifications are required to properly obtain a significant 

performance improvement. The flowchart in figure 7.12 illustrates how 

successive experiments are used to improve Software. '"^ 
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HYPOTHESIS 



\s 



DESIGN 
EXPERIMENT 



-iki 



MEASURE 



^k. 



ANALYZE 
DATA 



NO 



MODIFY 
(EXPERIMENT) 




YES 



NO 




YES 



NO 



fOALS 



"SATISFIED 
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END 
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PERFORMANCE IMPROVEMENT CYCLE - FIGURE 7.12 



APPENDIX .A 
SWL RESERVED WORD LIST 



ALIGNED 


NIL 




ALLOCATE 


NOT 




AND 


OF 




ARRAY 


OPEN 




BEGIN 


OR 




BY 


ORIF 




CASE 


PACKED 




CASEND 


POP 




CAT 


PROC 




CLOSE 


PROCEND 




CODE 


PUSH 




CONST 


QUEUE 




COPROC 


RECEND 




CRAMMED 


RECORD 




CREATE 


RFF 




CYCLE 


REL 




DEFINE 


REP 




DEQUEUE 


REPDEP 




DESTROY 


REPEAT 




DO 


RESET 




DOWNTO 


RESUME 




ELSE 


RETURN 




END 


REWIND 




ENQUEUE 


SEGMENT 




"" EXECUTE 


SEQ 




EXIT 


SET 




EXTERNAL 


STUCK 




FILE 


STATIC 




FOR 


STRING 




" FOREND 


. . TAG 




FREE 


THEN 




GOTO 


TO 




HEAP 


TYPE 




IF 


UNION 




IFEND 


UNPACKED 




IN 


UNTIL 




LABEL 


VAL 




LOOP 


VAR 




LOOPE^D 


WFOF 




MACRO 


WHEN 




MACROEND 


WHILE 




HOD 


WHILEND 




MODE 


XOCL 




MODEND 


XOR 




MODULE 


XPEF 





NEXT 



SWL RESERVED WORD LIST 
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APPENDIX B 
ERROR LIST 



WL ERROR MESSAGES - 1 FEB 75 

18 SCALAR TYPE EXPECTED, 

2% INTEGER TOO LARGE, 

^8 ERROR IN CONSTANT, 



it °=° EXPECTED, 

5? FIELD NAME DECLARED TWICE, 

68 BAD. RANGE. 

78 TAG FIELD TYPE BAD. 

88 NAME DECLARED TWICE, 

98 °) " EXPECTED, 



0? °!' EXPECTED. 

18 IDENTIFIER EXPECTED, 

2 8 IDENTIFIER NOT DECLARED, 

38 INDEX MUST BE OF SCALAR TYPE, 

<+S "OF EXPECTED, 

58 TYPE IDENTIFIER EXPECTED. 



68 PROCEDURE DECLARED TWICE, 

78 'END EXPECTED, 

88 ERROR IN TYPE DECLARATION, 

98 ERROR IN VARIABLE DECLARATION. 

08 ERROR IN INITIALIZATION VALUESc 

18 ERROR IN PROCEDURE DECLARATION, 



28 TOO MANY INITIALIZATION VALUES, 

38 PARAMETER LIST IGNORED, ' 

^8 ERROR IN DECLARATION PART, 

58 LOWBOUND > HIGHBOUNO, 

68 NOT A VARIABLE IDENTIFIER. 

78 DECREASING ADDRESSES IN VALUE PART, 



'88 SYMBOLIC SUBRANGE TYPE NOT ALLOWED. 

8 PARAMETER MISSING IN FUNCTION DECLARATION. 

SOS ILLEGAL COMPONENT TYPE. 

118 UNDECLARED IDENTIFIER. 

528 VARIABLE OR FIELD IDENTIFIER EXPECTED. 

538 EXPRESSION TOO COMPLICATED. 



5^8 TYPE OF VARIABLE SHOULD BE ARRAY, 

558 TYPE OF EXPRESSION MUST BE SCALAR, 

568 CONFLICT OF INDEX TYPE WITH DECLARATION. 

578 "l EXPECTED. 

58 8 TYPE OF VARIABLE SHOULD BE RECORD* 

598 NO SUCH FIEL D I N THIS RECORD. 

hO S TYPE OF VARIABLE SHOULD BE POINTER OR FILE. 

tit FIELD NAME EXPECTED. 

t28 ILLEGAL SYMBOL IN EXPRESSION. 

f38 UNDEFINED LABEL*, 

^8 ILLEGAL TYPE OF PARAMETER IN STANDARD FUNCTION OR PROCEDURE. 

>58 TY P E IDENTIFIER. IN STATEMENT PART. 

»6« PROCEDURE USED AS FUNCTION. 

til INTEGER EXPRESSION EXPECTED. 

t88 °) ° EXPECTED, 

*9 8 IDENTIFIER EXPECTED. 

50 8 ILLEGAL TYPE OF OPERAND. 

5U "OR° AND "XOR" CANNOT BE USED AS MONADIC OPERATORS. . 

528 •:=• EXPECTED. 

538 ASSIGNMENT NOT ALLOWED. 

8 ILLEGAL SYMBOL IN STATEMENT. 

;58 TYPE OR CONSTANT IDENTIFIER. 

568 °THEN" EXPECTED. 

578 TYPE OF EXPRESSION IS NOT BOOLEAN. . 

>8 8 "? ""EXPECTED, ' . 

598 °DO° EXPECTED, 

b08 ILLEGAL PARAMETER SUBSTITUTION. B_1 

*■* i i Ann CYDPfTPn, 



62? 
63S 
6*+? 
65? 
f>6? 

d88 

69: 
70? 
71? 
72? 
73? 



ILLEGAL TYPE OF EXPRESSION. 

CONSTANT EXPECTED. 

"J" EXPECTED. 

•OF" EXPECTED. 

TAG FIELD MISSING FOR THIS VARIANT. 

•UNTIL* EXPECTED. 



•END' EXPECTED. 

LOOP CONTROL VARIABLE MUST BE SIMPLE AND "LOCAL OR GLOBAL, 

"TO* OR "DOWNTO* EXPECTED. 

TOO MANY CASES IN CASE STATEMENT. " 

NUMBER OF PARAMETERS DOES NOT AGREE WITH DECLARATION. 
MIXED TYPES. 



7<+5 TOO MANY LABELS IN THIS PROCEDURE. 

75? TOO MANY LONG CONSTANTS OR YET UNDEFINED 

76? DEPTH OF PROCEDURE NESTING TOO LARGE. 

77 J LABEL DEFINED MORE THAN ONCE. 

78? TOO MANY EXIT LABELS. 

79? *(' EXPECTED. 



LABELS. IN THIS PROCEDURE, 



80 * % • EXPECTED. 

81! ASSIGNMENT TO FORMAL FUNCTION IDENTIFIER ILLEGAL. 

821 TOO MANY NESTED W ITH-STATEMENTS. 

83 t STANDARD IN-LINE PROCEDURE OR FUNCTION USED AS ACTUAL PARAMETER. 

8**? TOO MANY LONG CONSTANTS IN THIS PROCEDURE. 

85? ASSIGNMENT TO FUNCTION IDENTIFIER MUST OCCUR IN FUNCTION ITSELF. 

86? ACTUAL PARAMETER MUST BE A VARIABLE. 

87S VARIABLE MUST BE ALIGNED. 

88? OPERATORS •<■ AND •>• ARE NOT DEFINED FOR POWERSETS. 

8 9 ? REDUNDANT OPE RA T I ON N P OWE RSE TS . 

90? PROCEDURE TOO LONG. 

91? TOO MANY EXIT LA B ELS OR FORWARD PROCEDURES. 

~''S TOO MANY POINTER "TYPES OR FILE VARIABLES. 
v -..ot BAD FUNCTION TYPE. 

9ht ONLY ' = • AND •#■■ ALLOWED HERE. 

958 BAD FILE DECLARATION. ".' ~~ ',' ' ' """' ' ~ 

96? TYPE DECLARED TWICE. 

97? 'END.' ENCOUNTERED. . 

988 «t • EXPECTED. 

99? INDEX OUT OF RANGE. 
100? LABEL TOO LARGE. 

I'D It' VALUE IS OUT OF RANGE". ' ' : " " r ~~ 

102? DIVISION BY ZERO, 

103? PARAMETER PROCEDURE HAS MORE THAN 17 PARAMETERS. 



10<t! 
105! 
106? 
1078 
108? 
109! 



TEN OR MORE ERRORS ON THIS LINE. 

•;• NOT ALLOWED IN COMMENTS* COMMENT TERMINATED. 

IDENTIFIER TOO LONG. 

•MODULE' EXPECTED. 

•MODEND' EXPECTED. 
INVALID ATTRIBUTE. 



110? 'IFEND* EXPECTED. 

ill? TOO MANY ALTERNATIVES IN IF STATEMENT. 

112? •LOOPEND* EXPECTED. 

113? "WHILEND* EXPECTED. " 

il^! •FOREND* EXPECTED. 

115! END LABEL DOES NOT MATCH. 



116? 

J.17J 
< ! 

119? 
120! 
J._21Jt_ 
122! 
123! 
12<+! 
1 7^,1 



NESTING OF STATEMENTS AND PROCEDURES TOO DEEP. 

ILLEGAL REFERENCE TO LABEL OR PROCEDURE NAME. 

TOO MANY UNRESOLVED REFERENCES. 

'WHEN 8 EXPECTED. 

MORE THAN ONE LABEL ON STATEMENT. 

NO ENCLOSING PROCEDURE. 



CYCLE REFERENCE NOT TO REPETITION STATEMENT. 

•VAL* OR 'REF' EXPECTED. 

LOCAL CLASS MAY NOT BE REFERENCED BY EXTERNAL POINTER. 

VARTARIF MIKIT RF "sTATTr np ynri. 



B-2 



126: "PROCEND" EXPECTED. 

127! SYSTEM ERROR (INVALID RELOCATION). 

128 ! FEATURE NOT IMPLEMENTED. 

129: "RECEND" EXPECTED. 

1 SOt STORAGE OR SCOPE ATTRIBUTE EXPECTED, 

' ! "RECENO" EXPECTED. 



.l„«i» ILLEGAL BUILT-IN FUNCTION NAME. 

133* ILLEGAL CONVERSION FUNCTION OR VALUE CONSTRUCTOR TYPE. 

134! NOT SUPPORTED YET. 

135! "< • OR "[• EXPECTED. 

136! ELEMENT VALUE OUT OF RANGE. 

137! 'MODE* NOT SUPPORTED. 



138! FILE MAY NOT BE INITIALIZED. 

139! POINTER MAY ONLY BE INITIALIZED TO NIL. 

140! COMPILER ERROR (CTPTR = NIL IN CHECKTYPEBOUNDS) . 

141! SELECTION VALUE MUST BE ORDINAL* INTEGER, OR CHAR CONSTANT. 

142! MULTIPLE SPECIFICATION OF SELECTION VALUES. 

1 43! "CAS E N 0' EXPECTED. ' 

144! NUMBER OF INITIALIZATION VALUES EXCEEDS ISWL LIMITATION. 

145! NUMBER OF REPLICATIONS LESS THAN 1. 

146! •» ' OR •;• EXPECTED. 

147! STRING LENGTH ERROR. 

148! ILLEGAL OPERAND FOR CONCATENATION. 

149 ! I LLE G A L CONVERS ION FUNCTION IN CONSTANT. 

"150 J POINTER VARIABLE EXPECTED. 
151! STRING OR CHARACTER EXPRESSION EXPECTED. 
1528 CHAR EXPRESSION EXPECTED. 

1538 SUBSTRINGS OR STRING CONVERSIONS NOT ALLOWED AS PARAMETERS. 
154! IDENTIFIERS IN PRONGS LIST NOT DECLARED. 

1 5 51 ALL OR NONE OF IDENTIFIER LIST MUST BE PRONGS OF OUTERMOST MODULE, 
,"~SI MODULE NESTING ERROR. 

i. J ONLY VARS AND PROCS ALLOWED AS PRONGS OF OUTERMOST MODULE. 
1588 TOO MANY BLOCKS OR MODULES IN A COMPILATION UNIFJDEBUG TURNED OFF. 
159! SIZE OF SEQUENCE TYPE IS ZERO WORDS. 
160! SEQUENCE VARIABLE EXPECTED. 

161! 'REP* EXPECTED. • 

162! "IN" EXPECTED. 

163! NOT NESTED IN A REPOEP PROC. 

164! DECLARATION PART EXPECTED. 

165! DEBUG STATEMENT-NUMBER TABLE OVERFLOW? DEBUG TURNED OFF. 

166! DEBUG SYMBOL TABLE OVERFLOW? DEBUG TURNED OFF. 

167! STRING TYPE VARIABLE EXPECTED. 



168! DECIMAL SPECIFICATION IGNORED. 

169! INITIALIZATION VALUE AND ELEMENT NOT OF EQUIVALENT TYPE. 

170! VALUE MUST BE QUOTED STRING. 

171! TOO MANY VALUES FOR SUB-ARRAY. 

172! •[• OR 'REP I OF" EXPECTED. 

17 31 INSUFFICIENT VALUES FOR SUB-ARRAY. __ 

174! •]■ OR "," EXPECTED. 

175! INSUFFICIENT VALUES FOR RECORD. 

176! TOO MANY VALUES FOR RECORD. 

177! TAG FIELD MAY NOT BE INITIALIZED BY "'•*•". 

178! MUST BE A SET TYPE. 

179! THE OPERAND IS NOT A SET OR BOOLEAN. 



180! ILLEGAL CONSTANT FACTOR. 

181! "CAT" OPERATOR NOT PERMITTED HERE. 

! "PACKED" ATTRIBUTE CAN ONLY BE USED FOR ARRRAYS AND RECORDS. 

183! CANNOT CHANGE PACKING OF PREVIOUSLY DEFINED TYPE. 

184! DATA TYPE OF EXPRESSION TOO COMPLICATED. 

18 5 ! POINT E R TO PR OC EXPECTED. 

186! PROCEDURE HAS" VALUE PARAMETERS. 

187! FORWARD PROC ALREADY HAS ATTRIBUTES. 

188! STATEMENT NOT NESTED IN PROCEDURE. B " J 



190 S MORE THAN 1 ADAPTABLE FIELD IN RECORD OR AOAPTABLE FIELD IN CASES. 
191: POINTER TO TYPEIO EXPECTED. 
192: UNION VARIABLE EXPECTED. 

193* NOT A MEMBER OF THIS UNION. 

19/+J POINTER VARIABLE EXPECTED. 

1 "'» UNION S ARE N OT EQUIVALENT. ' 

l?6t UNION" OR POINTER VARIABLE EXPECTED. 

197* POINTER MAY NOT BE PASSED BY REF TO UNION" PARAMETER. 

198: POINTER VARIABLE EXPECTED ON LEFT OF ':=«". 

199* ARRAY VARIABLE EXPECTED. 

200: WRONG DIMENSION SPECIFICATION. 

2 01t '..* EXPECTED. . ■ 

202* NON-COMPARABLE STRUCTURES. 

203: 

204: WARNING : FIELD ASSUMED TO BE ALIGNED. 
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APPENDIX C 
LANGUAGE SUMMARY 



RESERVED WORD 



USAGE 



ALIGNED 

ALLOCATE 

AND 

ARRAY 

BEGIN 

BY 

CASE 

CAS END 

CAT 

CLOSE 

CODE 

CONST 

COPROC 

CRAMMED 

CREATE 

CYCLE 

DEFINE 

DEQUEUE 

DESTROY 

DO 

DOWNTO 

ELSE 

END 

ENQUEUE 

EXECUTE 

EXIT 

EXTERNAL 

FILE 

FOR 

FOREND 

FREE 

GOTO 

HEAP 

IF 

IFEND 

IN 

LABEL 

LOOP 

LOOPEND 

MACRO 

MACROEND 

MOD 

MODE 

MODEND 

MODULE 

NEXT 



ALLOCATE P ; 

REPEAT S UNTIL A AND B; 

VAR X: ARRAY £l..lOl OF INTEGER; 



CASE TAG OF =1= S; =2= S; CASEND; 
CASE TAG OF =1= S; =2= S; CASEND; 
VAR S: ESTATIC] STRING(6) OF CHAR 
CLOSE (Fl); 



:= »ABC» CAT »DEF ! 



CONST LIMIT = 100; 



REPEAT SI, CYCLE WHEN K10; S2; UNTIL 1=100; 



FOR I:= 1 TO 10 DO SI; FOREND; 

FOR I:= 100 DOWNTO 1 DO SI; FOREND; 

IF K100 THEN SI; ELSE S2; IFEND; 



LOOP SI; EXIT WHEN 1=10; S2 ; LOOPEND; 

VAR Fl [OUT] : FILE OF CHAR; 
FOR I:= 1 TO 10 DO SI; FOREND; 
FOR I:= 10 DOWNTO 1 DO SI; FOREND 
FREE P; 
GOTO LI; 

IF K 10 THEN SI; IFEND; 
IF I<=100 THEN S2; IFEND; 
B:= 5 IN SETA; 
LABEL L1,L2,L3,L4; 
LOOP SI; LOOPEND; 
LOOP SI; LOOPEND; 



MODULE TEST;Sl;S2; MODEND TEST; 
MODULE TEST;S1;S2; MODEND TEST; 
NEXT P IN SEQVAR; 



SWL LANGUAGE SUMMARY 



AP^t* 



<( 



i RePWf 
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RESERVED WORD 



USAGE 



NIL 

NOT 

OF 

OPEN 

OR 

ORIF 

PACKED 

POP 

PROG 

PROCEND 

PUSH 

QUEUE 

RECEND 

RECORD 

REF 

REL 

REP 

REPDEP 

REPEAT 

RESET 

RESUME 

RETURN 

REWIND 

SEGMENT 

SEQ 

SET 

STACK 

STATIC 

STRING 

TAG 

THEN 

TO 

TYPE 

UNION 

UNPACKED 

UNTIL 

VAL 

VAR 

WEOF 

WHEN 

WHILE 

WHILEND 

XDCL 

XOR 

XREF 



P:=tfIL 

IF NOT #EOF (INPUT) THEN SI; IFEND; 

VAR S: STRING (10) OF CHAR; 

OPEN (Fl); 

B:= A OR B; 

IF B THEN SI; ORIF A THEN S2 ; IFEND; 

VAR X: PACKED ARRAY [l..IO] OF 0..8; 

PROC NAME; S1,S2; PROCEND; 
PROC NAME; S1,S2; PROCEND; 



TYPE R= RECORD F1,F2: INTEGER RECEND; 
TYPE R= RECORD F1,F2: INTEGER RECEND; 
PROC NAME (REF I .-INTEGER); S1;S2; PROCEND; 

VAR X: [STATIC*] ARRAY [l..lO] OF INTEGER :=[ REP 10 OF 0] ; 
PROC [REPDEP] NAME; SI, S2; PROCEND; 
REPEAT SI UNITL I<6; 
RESET P; 

RETURN WHEN K10; 
REWIND (INPUT); 

VAR Q:SEQ (REP 10 OF R) ; 

VAR X: []STATIC3 ARRAY [l..lo] OF INTEGER := [,REP 10 OF o] ; 
VAR S: STRING (10) OF CHAR; 

IF K10 THEN SI; IFEND; 

FOR I:= 1 TO 10 DO; 

TYPE ORD= (RED, BLUE, GREEN); 

TYPE U= UNION (AReal, A INTEGER); 

REPEAT SI UNTIL >=10; 

PROC NAME (VAL I: INTEGER); S1,S2; PROCEND; 

VAR I: INTEGER; 

WEOF (INPUT); 

EXIT WHEN K10; 

WHILE K10 DO S1;S2; WHILEND; 

WHILE B DO SI; S2 ; WHILEND; 

PROC [XDCL] MAIN; 

B:= A XOR B 

PROC [XREF] SWLSMP; 



SWL LANGUAGE SUMMARY 
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APPENDIX E 
ANNOTATED TERMINAL SESSION 



• 75/03/13. 10*43. 55. 

MIDWEST CLUSTER C E N T E R / SYSTEM F 
USER NUMBER: ED>R325T1 
TERMINAL: 101*713 



KR0N0S 2.1 .0-06 



REC0VER/ CHARGE: CHARGE > T3726MX* *SWL* 



READY. 






HALF 

READY. 



... 1 . LOGIN PROCEDURES . 
2. THIS TERMINAL RUNS IN HALF- 



DUPLEX. — THIS COMMAND TELLS 
KRONOS. 



3. SPECIFY NEW PRIMARY 
FILE NAMED SUM. 



*l < 



NEW* SUM 
READY. 



X 



TEXT 

ENTER TEXT M0DE ■ 



M0DULE SUM 

PR0C CXDCL] MAIN; 

VAR Is [STATIC] INTEGER := 

"SKIP EMPTY LINES" 



4. USING TEXT MODE ENTER 

ENTIRE PROGRAM. TERMINATE 
TEXT MODE WITH BREAK KEY. 



H 



WHILE #E0F( INPUT) D0 
WHILENDJ 

"READ & SUM INPUT ''LINE 7 '' 

READCN) 

WHILE N0T #E0F< INPUT) D0 



5. PACK CCMMAND REQUIRED 
AFTER TEXT MODE INPUT. 



t 



I=I+N* 

READCN) 
WH I LEND 5 

"WRITE RESULT" 

WRITEC SUM s M,E0L)l 



6. SAVE SOURCE PROGRAM AS 
INDIRECT FILE NAMED SUM. 



M0DEN D SUM; 

EXIT TEXT ""M0DE. 
PACK 



id 



SAVE 
READY. 



ANNOTATED TERMINAL SESSION 
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I 



■BATCH 
SRFL»20000. 
/ATTACH, ISWL/UN=ALL 
/GET»ISWLLIB/UNsALL 



7. OBTAIN COPY OF COMPILER 
AND RUN TIME ROUTINES. 



/RFL> 105000 
RFL, 105000. 
/ISWL, I = SUM 



1 

OCDC 



CY3ER SYSTEM 



ISWL 2.0 



LEVEL 1 



75/03/13. 



10.50.45. 



PAGE 



1 



000001 
000063 

**** 
000063 



! MODULE SUM 

1PR0C CXDCL] MAIN J 

t58 
!VAR I:CSTATIC1 INTEGER := 



000064 
000064 
000064 

s|e % 3ft 3$e 

000070 
000071 



!"SKIP EMPTY LINES" 
1WHILE #E0F(INPUT> D0 

ti'46' 

! WHILENDl 
e 



"ISWL,I=SUM" CAUSES COMPILER 
TO CCMPILE SOURCE PROGRAM AND 
PRINT LISTING AT THE TERMINAL. 
ERROR LINES ARE SHOWN. 



000071 !"READ * SUM INPUT LINE" 

000071 IREADCN) 
**** t31 

000071 ! WHILE ^ NOT #EWTfNPUfT""D¥'' 
**** t58 

000072 !I=I+NJ 



000072 

000072 
000073 
000073 



t52 
!READ(N> 

t31 



IWHILENDi 



! "WRITE RESULT" 



000073 
000107 
000107 

■^ ^p- ^5 ^p 

000107 



JWRITEC SUM = MiE0D) 
j 

1M0DEN D SUM* 

'" t'3'1 ' ' t'52 

r 



* STK FRAME ADDR. 
/ 



* 105263 



9. COMPILER "BLOWS UP", 



ANNOTATED TERMINAL SESSION 
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• EDIT 

BEGIN TEXT EDITING. 
? L 

MODU LE SUM 

? RS:/SUM/#/SUMi/ "" 

? Sil 

? L 

PR0C CXDCLI MAIN? 

? S;i 

? L 

VAR ItCSTATICl INTEGER := 
? RSt/0/»/Ol/ 

? F:/READ/ 

"READ & SUM INPUT LINE" 

? SJ1 

? L 

HEAD(N) 

? RS:/)/*/) i/ 

? F:/M0D/ 

M0DEN D SUMJ 

? RS:/N D/./ND/ 

? END 
■ END TEXT EDITING. 

$EDIT,SUM. 
'/REPLACE 

/ 



10. BEGIN TEXT EDITING THE 
PRIMARY FILE CORRECTING 
ERRORS. 



11. WHEN EDITING COMPLETE 
REPLACE OLD PERMANENT 
FILE COPY WITH REVISED 
(EDITED) COPY. 



ANNOTATED TERMINAL SESSION 
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<z C 



/3 



/ISWL* I=SUM,0=Z 
* NUMBER 0F SYNTAX ERR0RS 
8-/EDIT,Z 

BEGIN TEXT EDITING. 
? F:/****/ 



12. BECQMPILE EDITED PRIMARY 

FILE (SIM) AND PLACE LISTING 
ON FILE 2. 



**** 


t31 


? SJ-1 




? LJ3 




000071 


JREADCN) J 


**** 


t31 


000071 


! WHILE N0T #E0F( INPUT) D0 


? END 




END TEXT EDITING. 


SEDIT.Z 


• 


/EDIT 




BEGIN 


TEXT EDITING. 


? Fi/VAR/ 



13. SINCE THERE ARE ERRORS, EDIT 



FILE 2, FIND ERROR. 



I 



14. TO CORRECT ERROR "WE MUST 
EDIT THE PRIMARY FILE. 



// 



VAR I:CSTATIC3 INTEGER : = 01 
? RS:/0J/,/0>/ 

? ADD 

ENTER TEXT. 
? • NMNTEGERJ* 

READY. 



15. REPLACE PERMANENT FILE 
WITH NEW PRIMARY FILE. 



is c; 



? END 
END TEXT EDITING. 
U -$EDIT>SUM. 
/REPLACE 



ANNOTATED TEKMINAL SESSION 
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r-RETURN*LG0*Z 

L$RETURN*LG0*Z. 

p/ISWL* I=SUM*0=Z 

L* NUMBER 0F SYNTAX ERRORS 

r /EDIT*Z 



16. RETURN OBJECT FILE (LGO) 

AND LISTING FILE (2). THIS IS 

A QUICK WAY OF EMPTYING THESE FILES. 



BEGIN TEXT EDITING. 
? Ll* 
t 

OCDC CYBER SYSTEM 
75/03/13. 



ISWL 2.0 



10.58.30. 



LEVEL 1 
PAGE 1 



000001 
000063 
000063 
00006 4 
000064 
000064 



M0DULE SUM! 
PR0C CXDCLH MAIN* 
VAR Is [STATIC] INTEGER 
N: INTEGERS 

"SKIP EMPTY LINES" 



:= 0* 17. RECOMPILE "WITH LISTINGS ON 
FILE 2. 



000064 
000070 
000071 
000071 
000071 
000073 



WHILE #E0F<INPUT> D0 
WHILENDJ 

"READ * SUM INPUT LINE" 

READ<N)J 

WHILE N0T #E0F < INPUT >D0 



18. EDIT FILE 2 AND OBTAIN A 

COMPUTE COMPILATION LISTING. 



000074 

**** 

000074 

000076 

000077 

000077 



I«I.+NJ 

t52 
READ(N) 
W HI LEND J 

"WRITE RESULT" 



000077 
0001 13 
0001 13 
**** 



WRITEC SUM = *«I,E0L>! 

M0DEND SUMJ 

1 126"*" 58 



•END 0F FILE- 



*»•> 



END 
END TEXT 
$EDIT*Z. 
/ 



EDITING, 
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l—EDIT 

BEGIN TEXT EDITING. 
? F:/I=I/ 
I=I+N; 



19. MAKE CORRECTIONS TO EDIT FILE. 



K 



? RS:/=/,/:=/ 

? F+ *DEL* 
Ft/M0DEND/ 
M0DEND SUM J 
? SJ-1 
? ADD 



ENTER TEXT. 
? 'PR0CEND MAIN!' 

READY. 
? END 

END TEXT EDITING. 
•$EDIT*SUM. 



20. REPLACE PERMANENT FILE WITH 



C /REPLACE 



CONTENTS OF PRIMARY FILE. 



23 
21 

2r 



RETURN, L0 *DEL* 
RETURN.- LG0.-Z 



21. CLEAR OUT FILES LGO & 2. 



I 



$RETURN,LG0*Z. 
/ISWL, I=SUM,0=Z 
- END C0MPILATI0N 
/LG0 

? 3 5 7 9 
SUM = 24 



22. RECOMPILE PRIMARY FILE. 
NOTICE NO COMPILATION ERRORS. 

23. EXECUTE PROGRAM. INPUT 



END EXECUTI0N 

/LG0 
■> 






♦INTERRUPTED* 



DATA AFTER? 

24. EXECUTE AGAIN. THIS TIME 
TEST AN EMPTY INPUT LINE. 



♦TERMINATED* 



/EDIT 
BEGIN TEXT EDITING. 



25. AFTER A FEW MINUTES WITH NO 
RESPONSE WE REMEMBER THAT 
THE "REWIND(INPUT)" STATEMENT 
WAS OMITTED. BREAK KEY IS 
USED TO TERMINATE EXECUTION. 



u 



? F:/WHILE/ 

WHILE #E0F( INPUT) D0 

? LJ3 

WHILE #E0F< INPUT) D0 

WHILENDJ 



26. USE EDIT TO ADD MISSING 
LINE IN PRIMARY FTT.E. 



? ADD 

ENTER TEXT. 
? 'REWINDCINPUT)! ' 

READY. 
? END 

END TEXT EDITING. 



27. REPLACE PERMANENT FILE. 
EMPTY LGO & 2. 



21 



»-$EDIT,SUM. 

r/REPLACE 
/RETURN, LG0,Z 
$RETURN,LG0,Z. 
/ISWL, I=SUM,0=Z 

<*•- END C0MPILATI0N 



RECOMPILE. 
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r-LG0 

? 2 3 4 5 

SUM a. 



14 



■*-- END EXECUTION 
I-/LG0 



? 33 44 55 

SUM = 



132 



28. TEST PROGRAM WITH INPUT DATA. 



29. TEST PROGRAM "WITH EMPTY INPUT 
LINES. 



I 1 -- END EXECUTION 



£./SAVEj 


-LG0=SUMLG0 




30. 


SINCE PROGRAM WORKS SAVE THE 


J-/BYE 








BINARY OBJECT DECK AS A FILE 
CALLED SUMLGO FOR FUTURE USE. 


ZED 


L0G 0FF. 


11 .06.02. 






ZED 


SS 


10.369 SEC. 


31. 


LOGOFF. 


Ltig 


3532 









ANNOTATED TERMINAL SESSION 



E-7 



APPENDIX F 
COMPILATION LISTING 



COMPILATION 
DATE 
YY/MM/DD 



TIME OF 
COMPILATION 
HH.MM.SS. 



COMPUTER SYSTEM 



CCMPILER & VERSION 



1- 



i 

OCDC CYBER SYSTEM 
75/03/12.' 



ISWL 2.0 



19.45.09. 



LEVEL 1 
PAGE 1 



000001 
000063 



MODULE L00PSJ 



000063 
000063 
000063 
000063 
000063 
000063 



PR0C CXREF3 SWLSMP CVAL M>N: INTEGER) BOOLEAN; 

PR0C CXDCL3 MAINJ 

LABEL L1»L2; 

CONST L0PC0UNT = 1 00000 1 



000063 
000063 
000063 
000072 
0001 12 
000131 



VAR I : INTEGER? 

IF SWLSMP <0+472<8)*162<8>+472<8>> 

THEN WRITEC SWLSMP OUTPUT FOLLOWS* , E0L > ; 
ELSE WRITEC SWLSMP NOT AVAILABLE ',E0L)J 

IFENP; ; 



000131 
000131 

000132 
000132 
000135 



LI :F0R I := 1 T0 L00PC0UNT D0 

t3l « 

FOR L00P" " ^. \ ERR0R 

F0REND; 



DESIGNATION 



000135 
000136 
0001 36 
0001 40 
0001 40 

T* *f* *T* vr 



L2: 1 2=0 5 

REPEAT 

1 5 = I + 1 ; 

"REPEAT L00P M 

UNTIL I >= L00PC0UNT* 
L31 



000141 

►000141 

000143 



PR0CEND MAIN; 
M0DEND L00PS5 



* NUMBER 0F SYNTAX ERR0RS = 



2 



ERROR 
SUMMARY 



LOCATION OF SOURCE STATEMENT 

FROM BEGINNING OF MODULE (IN OCTAL). 
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APPENDIX G 
CHARACTER CODES 



The character codes illustrated are specifically 
for the CDC 713 Terminals. Since the 713 Terminal 
follows the standard ASCII character coding.the 
codes shown will probably be the same for any 
ASCII Terminal. 



"$K* $M80 

MODULE CHARACTER$SET$713; 

DISPLAY CODES FOR CDC 713 TERMINALS 
DRIVEN UNDER KRONOS 2.1 LEVEL 6 



G0WST 

" NAME 

NUL 
SOH 

—- STX— 
ETX 
EOT 
ENQ 
ACK 
BELL 

— - BS 



VALUE 

= $CHAR( 
= $CHAR( 
=--$CHftRt~ 



0)* 
1), 



DESCRIPTION 

"NULL OR IDLE 
"START OF MESSAGE 



ASCII 



OPR CHR GRP "! 



0000 
0000 



0000 
0001 



N 
N 



SCHARI 
$CHAR( 
$CHAR( 
$CHAR( 
SCHAR( 



3) 

k) 

5) 

6) 
7) 



-" START OF TEXT 

"END OF TEXT 

"END OF TRANSMISSION 

"ENQUIRY 

"ACKNOWLEDGE 

"BELL 



Q00Q 0010 



N 

N 

-N- 



0000 
0000 
0000 
0000 
0000 



0011 
0100 
0101 
0110 
0111 



Y 
N 

N 
N 
N 



-*-*€HAR-C 8+ 



HT 
LF 
VT 
FF 

CR 



$CHAR{ 
$CHAR( 
$CHAR( 
$CHAR( 
$CHAR( 



9), 

10), 
11), 
12)t 
13), 



1000 



-so — 

SI 

DLE 

DC1 

DC2 

DC3 

D€*r— 

SKIP 

LCLR 

ETB 

CLR 

RSET 

CUP 

ESC 

FS 



-«-$eH ARC 14) 



$CHAR( 
SCHARC 
$CHAR( 
$CHAR( 
$CHAR( 
-SGHAR-t- 



15), 
16), 
17), 
18), 
19), 
-20+ 



'CURSOR LE F T (QACKSPACE) 

•HORIZONTAL TAB 

'LINE FEED (EOL) 

"VERTICAL TAB 

'FORM FEED 

■CARRIAGE RETURN 

■S H i r T OUT (BLACK ON W H ITE) — fr*frfl— 1«*- 



Y 
N 
N 
N 
N 
-N- 



0000 
0000 
0000 
0000 
0000 



1001 
1010 
1011 
1100 
1101 



"SHIFT IN (WHITE ON BLACK) 



CONTROL 
CONTROL 
CONTROL 
CONTROL 



$CHAR( 
$CHAR( 
$CHAR( 
$CHAR( 
$CHAR( 
$C+4ARt 
$CHAR( 
$CHAR( 



21) 
22) 
23) 
Zk) 
25) 
26 * 
27) 
28) 



"DEVICE 

"DEVICE 

"DEVICE 

"DEVICE 

•^BE-V-ICE-C-OHTR-OL- 

"CURSOR RIGHT (SKIP) 

"LINE CLEAR 

"ENO TRANSMISSION BLOCK 

"CLEAR SCREEN 

"RESET CURSOR (TO HOME) 

"C0R50R-UP - - 

"ESCAPE 

"FIELD SEPARATOR 



0000 
0001 
0001 
0001 
0001 



1111 
0000 
0001 
0010 
0011 



00 1 -frfrBfl- 



0001 
001 
0001 
0001 
0001 
001 
0001 
0001 



0101 
0110 
0111 
1000 
1001 

loia 

1011 
1100 



N 
Y 
N 
N 
Y 

-Y- 
Y 
N 
N 
N 
N 

-n 

Y 
Y 

N 
Y 
Y 

Y 

N 
N 



N 
N 
N 
N 
N 

■— ¥- 
Y 
N 
N 
N 
N 

■-N- 
N 
N 
N 
N 
N 
N 
N 
N 



Ofl | 



CHARACTER CODES 



G-l 



GS 


= 


$CHAR( 29), 


"GROUP SEPARATOR 


0001 1101 


N 


N 


•• f 


RS 


= 


$CHAR< 30), 


"RECORD SEPARATOR 


0001 1110 


N 


N 


it | 


US 


= 


$CHAR( 31), 


"UNIT SEPARATOR 


0001 1111 


N 


N 


• • f 


SP 


s 


$CHAR< 32), 


"SPACE 


0010 0000 


y 


N 


at § 


EX 


= 


$CHAR( 33), 


"EXCLAMATION MARK 


0010 0001 


Y 


Y 


•i g 


DQ 


= 


$CHAR{ 34) , 


"DOUBLE QUOTE 


0010 0010 


Y 


Y 


it g 


PS 


= 


$CHAR( 35), 


"NUMBER SIGN 


0010 0011 


Y 


Y 


it f 


OS 


= 


$CHAR< 36), 


"OOLLAR SIGN 


0010 0100 


Y 


Y 


** f 


PER 


= 


$CHAR( 37), 


"PERCENT SIGN 


0010 0101 


Y 


Y 


it 1 


AMP 


.— 


--$CH*R-f 38), 


"AMPERSAND 


0-MQ— 8-ltB- 


¥ 


---Y 


at f 


RAP 


s 


$CHAR( 39), 


"RIGHT APOSTROPHE 


0010 0111 


Y 


Y 


■a | 


LP 


= 


SCHARC 40), 


"LEFT PARENTHESIS 


0010 1000 


Y 


Y 


• | 


RP 


s 


$CHAR{ 41), 


"RIGHT PARENTHESIS 


0010 1001 


Y 


Y 


** I 


AS 


r 


$CHAR( 42), 


"ASTERISK 


0010 1010 


Y 


Y 


49 


PL 


- 


$CHAR( 43), 


"PLUS 


0010 1011 


Y 


Y 


** i 


CM 


= 


$CHAR( 44), 


"COMMA 


0010 1100 


Y 


Y 


•• | 


- -MI- -- 


-=- 


»pu« D t fiCi 


••MTLWI4C 


nni n 1 mi 


y 


v 


•t § 


junftK \ — **? i , 


frirrttrj 


TJTJlnJ irxtrt 


T 


f 




PERD 


s 


$CHAR( i»6), 


"PERIOD 


0010 1110 


Y 


Y 


•• | 


SOL 


x 


$CHAR( <*7), 


"SLASH OR SOLIDUS 


0010 1111 


Y 


Y 


at | 


ZER 


s 


$CHAR{ t»8), 


"ZERO 


0011 0000 


Y 


Y 


•• § 


ONE 


X 


$CHAR< «»9), 


"ONE 


0011 0001 


Y 


Y 


*• i 


TWO 


= 


$CHAR(,50), 


"TWO 


0011 0010 


Y 


Y 


at g 


T-HR ■— 

FOUR 


«.' 


4pu Apf C 1 1 


••TUP FP 


n n 1 -I n n 1 1 


v 


Y 


•• § 


= 


$CHAR( 52), 


"FOUR 


uuix uuii 
0011 0100 


Y 


I 

Y 


*• f 


FIVE 


= 


$CHAR< 53), 


"FIVE 


0011 0101 


Y 


Y 


«• | 


SIX 


= 


$CHAR( 5<t), 


"SIX 


0011 0110 


Y 


Y 


tt { 


SEV 


■= 


$CHAR( 55), 


"SEVEN 


0011 0111 


Y 


Y 


at y 


EGH 


= 


JCHAR( 56), 


"EIGHT 


0011 1000 


Y 


Y 


it | 


N-IN 


_--. 


*pU ftp / C7J 


"MTK1C 


GO 11-1841 — 


— ¥-- 


Y 


ii| 


tpUn HK I 5f if 


Pi A INt 




COL 


s 


$CHAR( 58), 


"COLON 


0011 1010 


y 


Y 


«t , 


SC 


- 


$CHAR( 59) , 


"SEMI-COLON 


0011 1011 


Y 


Y 


it g 


LT 


= 


$CHAR( 60), 


"LESS THAN 


0011 1100 


Y 


Y 


"! 


EQ 


= 


$CHAR( 61), 


"EQUAL 


0011 1101 


Y 


Y 


■a | 


GT 


= 


$CHAR( 62), 


"GREATER THAN 


0011 1110 


Y 


Y 


tt | 


QM 


■s- 


$CHAR<- 63),- 


"QUESTION- MARK 


0011 1111 


Y 


Y 


tt § 


AT 


= 


$CHAR( 6U, 


"AT SIGN 


0100 0000 


Y 


Y 


tt g 


A 


= 


SCHARC 65), 


"UPPER CASE A 


0100 0001 


Y 


Y 


• e g 


B 


= 


SCHAR( 66), 


"UPPER CASE 8 


0100 0010 


Y 


Y 


St f 


C 


= 


$CHAR( 67), 


"UPPER CASE C 


0100 0011 


Y 


Y 


it | 





= 


$CHAR( 68), 


"UPPER CASE D 


0100 0100 


Y 


Y 


•• | 


E 


--=. 


$CHA£ < 69) , - 


"yP PER -CASE E 


0104 GlOl 


Y 


Y 


«t f 



CHARACTER CODES 



G-2 



F 


= $CHAR( 70), 


, "UPPER CASE F 


0100 


0110 


Y 


Y 


"! 


G 


= SCHARt 71), 


, "UPPER CASE G 


0100 


0111 


Y 


Y 


"! 


H 


= $CHAR( 72), 


, "UPPER CASE H 


0100 


1000 


Y 


Y 


..j 


I 


= $CHAR( 73), 


, "UPPER CASE I 


0100 


tool 


Y 


Y 


■• g 


J 


= $CHAR< 7k). 


, "UPPER CASE J 


0100 


1010 


Y 


Y 


• ft g 


-K- - 


-■=-$GHA-R f-7-5-h 


» ^URP£#--€-A5£— K 


-0-1-&Q-. 


-4044- 


— ■-¥- 


--Y- 


»?4 


L 


= $CHAR( 76), 


, "UPPER CASE L 


0100 


1100 


Y 


Y 


•• 8 


M 


= SCHARC 77), 


, "UPPER CASE H 


0100 


1101 


Y 


Y 


ao g 


N 


= $CHAR( 78), 


, "UPPER CASE H 


0100 


1110 


Y 


Y 


IC | 





= $CHAR( 79), 


, "UPPER CASE 


0100 


1111 


Y 


Y 


•0 g 


P 


= $CHAR( 80), 


, "UPPER CASE P 


0101 


0000 


Y 


Y 


tf | 


Q 


= $CHAR< *4), 


, "'UPPER S-ASE-GH ■—- 


0101- 


0001 


¥ 


¥ 


«• 1 


R 


= $CHAR( 82), 


, "UPPER CASE R 


0101 


0010 


Y 


Y 


Of |' 


S 


= $CHAR( 83), 


, "UPPER CASE S 


0101 


0011 


Y 


Y 


•• 1 


T 


= $CHAR( 8*»), 


, "UPPER CASE T 


0100 


0100 


Y 


Y 


"! 


U 


= $CHAR( 85), 


, "UPPER CASE U 


0100 


0101 


Y 


Y 


si g 


V 


= $CHAR( 86), 


► "UPPER CASE V 


0100 


0110 


Y 


Y 


•• § 


w 


— tPM AP # ft7i 


"IIPPFP f*A^F* W 


m nn 


nm 


Y 


y 


•■ f 


— JpunMrc \ o f 9 \ 


» UrrtK UAat W 


UlUU 


UX11 


T 


i 




X 


= $CHAR( 88), 


, "UPPER CASE X 


0100 


1000 


Y 


Y 


it f 


Y 


= $CHAR( 89). 


, "UPPER CASE Y 


0100 


1001 


Y 


Y 


«• | 


Z 


= $CHAR( 90), 


, "UPPER CASE Z 


0100 


1010 


Y 


Y 


it § 


OB- 


= $CHAR( 91), 


, "OPEN BRACKET 


0100 


1011 


Y 


Y 


•• | 


BSH 


= $CHAR( 92), 


, "BACK SLASH 


0100 


1100 


Y 


Y 


•* 1 


-pa 


— »PM AP t Q71 . 


*• p i n^£* flo/iri^PT 


-9404- 
0100 


4-tOi — 
1110 


Y 


Y 


01 | 


CIR 


= $CHAR( 9<*) 


, "CIRCUMFLEX 


** i 


UNO 


= $CHAR( 95), 


, "UNDERSCORE 


0100 


1111 


Y 


Y 


««| 


LSQ 


= $CHAR( 96), 


, "LEFT SINGLE QUOTE 


0101 


0000 


Y 


Y 


"I 


LCA 


= $CHAR( 97), 


, "LOWER CASE A 


0101 


0001 


Y 


Y 


"j 


LCB 


= $CHAR( 98). 


, "LOWER CASE B 


0101 


0010 


Y 


Y 


8« g 


LCC 


= $CHAR( 99). 


, "LOWER CASE C 


0101 


0011 


Y 


Y 


•I g 


Leo- 


-~$ettAftt484h 


— — eflj fVtjco -p-Ji Q c r» 


n, n. 


n i n n 


V 


\j 


8 * • 


f LTUWtK WMJL U 


iriU 1 


1UU 


r 


Y 




LCE 


= $CHAR(101). 


, "LOWER CASE E 


0101 


0101 


Y 


Y 


«fi g 


LCF 


= $CHAR(10 2) 


, "LOWER CASE F 


0101 


0110 


Y 


Y 


80 | 


LCG 


= $CHAR(103), 


, "LOWER CASE G 


0101 


0111 


Y 


Y 


98 | 


LCH 


= $CHAR(10U< 


, "LOWER CASE H 


0101 


1000 


Y 


Y 


11 


LCI 


= $CHAR(105), 


, "LOWER CASE I 


0101 


1001 


Y 


Y 


86 g 


LCJ 


~»-«eHAR-C ***->-■> 


i "LOWER- CASE- J - - - 


8101 


1018- 


_._Y._._. 


Y 


i« g 


LCK 


= SCHARC107). 


, "LOWER CASE K 


0101 


1011 


Y 


Y 


• 9 g 


LCL 


= $CHAR(108), 


, "LOWER CASE L 


0101 


1100 


Y 


Y 


•■ 1 


LCM 


= $CHAR(109), 


, "LOWER CASE M 


0101 


1101 


Y 


Y 


• fl g 


LCN 


= $CHAR(110), 


, "LOWER CASE N 


0101 


1110 


Y 


Y 


11 9 



CHARACTER CODES 



G-3 



f — S OR = $CHAR(12t») 



LCO 
LCP 
LCQ 
LCR 
LCS 
LCT 
LCU 
LCV 
LCW 
LCX 
LCY 
LCZ 
OBR 



$CHAR( 
$CHAR( 
$CHAR( 
$CHAR( 
$CHAR( 
$CHAR( 
$CHAR{ 
SCHAR-f 
$CHARC 
$CHAR( 
$CHAR( 
$CHAR( 
JCHARt 



111), 
112), 
113), 
11U, 
115), 
116), 
117), 

ttaw 

119), 
129), 
130), 
131), 
123), 



•LOWER CASE 
'LOWER CASE P 
"LOWER CASE Q 
'LOWER CASE R 
•LOWER CASE S 
•LOWER CASE T 
'LOWER CASE U 
'L0WER~eA3E-V 
'LOWER CASE W 
'LOWER CASE X 
'LOWER CASE Y 
•LOWER CASE Z 
•OPEN BRACE 



0101 
0110 
0110 
0110 
0110 
0110 
0110 



1111 

&0&0 

0001 
0010 
0011 
0100 
0101 



Y 
Y 
Y 
Y 
Y 
Y 
Y 



Y 
Y 
Y 
Y 
Y 
Y 
Y 



-8110-8410 
0110 0111 



0110 
0110 
0110 
0110 



1000 
1001 
1010 
1011 



Y 
Y 
Y 
Y 
Y 



Y 
Y 
Y 
Y 
Y 



^ TYLIZC B- OR (VERTICAL OAR) 01 1 U Ofl- 



"! 

"8 



CBR 

TL 

RO 



$CHAR< 
$CHAR( 
$CHAR( 



125), 
126), 
127); 



"CLOSE BRACE 

•TILDE 

'RUBOUT 



$CHAR(128) .. $CHAR(255) PRINT AS A SPACE 
-AND-AfiE-tWAS5-I&J4&B~-A5€l-I GRAP H I CS 



0110 1101 
0110 1110 
8110 1111 

ON THE TERMINAL 



Y 
Y 
Y 



Y 
Y 
Y 



FOR A DETAILED DESCRIPTION OF CONTROL DATA 
CODES REFER TO - 



713 TERMINAL 



CONTROL DATA 713 CONVERSATIONAL DISPLAY TERMINAL 

HARDWARE PROGRAMMING REFERENCE WA-NUAL 

PUBLICATION NO. 62033^00 (JUNE, 1971) 

OPR - INDICATES WHETHER A DISPLAY OPERATION IS PERFORMED (CURSOR MOVED) 
CHR - INDICATES WHETHER A CHARACTER IS DISPLAYED ON THE TERMINAL SCREEN 
GRP - SHOWS THE GRAPHIC ACTUALLY DISPLAYED ON THE TERMINAL SCREEN 



"L. 



"I 
••• 



MODENO CHARACTER$SET$713; 



CHARACTER CODES 



G-4 



APPENDIX H 
SWL BNF (ALPHABETICAL) 



5 
6 
7 



10 

11 



12 

13 

14 



15 

16 
17 
18 

19 



<A CASES ::= =<SELECTION SPEC>[ »<SELECTION SPECs]= 
<STATEMENT LIST> 

<A POINTER CONFORMITY CASE> ::= 

=<POINTER TYPE SPECIFIER>= <STATEMENT LIbT> 

<A VALUE CONFORMITY CASE> :: = 

=<VALUE TYPE SPECIFIER>= <STAT£MENT L1ST> 



<ACCESS ATTRIBUTE> : 
<ACCESS ATTRIBUTES> 
<ACTUAL FILE NAMES ; 



= READ A WRITE \ EXECUTE 

:= <ACCESS ATTRIBUTES!, <aCCESS ATTRIBUTES] 

= <STRING EXPRESSIONS 



<ACTUAL PARAMETER LIST> ::= 

(<ACTUAL PARAMETERS! ,<ACTUAL PARAMETER>J) 
\<EMPTY> 

<ACTUAL PARAMETERS ::= <EXPRESS ION>\<PPOCEDURt IDENTIFIERS 

\<LABEL> 

<ADAPTABLE AGGREGATE TYPE> : := <ADAPTABLE STRlNG> 

\<ADAPTABLE ARRAY> 
\<ADAPTABLE RECORD> 

<ADAPTABLE ARRAY IDENTIFIERS ::= <IDENT IF IEk> 

<ADAPTABLE ARRAY SPEO s: = 

ARRAY t<STARRED LIST>] OF <TYPE> 
\ARRAY [<STARRED LIST>] OF <ADAPTABLE COMPONENT TYPE> 
\ARRAY 1<INDICES>J OF <ADAPTABLE COMPONENT TYPE> 

<ADAPTABLE ARRAY> : := [ <PACKING>]<ADAPTABLE AKRAY IOENTIFIER> 

\£<PACKING>3<ADAPTABLE ARRAY SPEO 

<ADaPTABLE COMPONENT TYPE> ::= <ADAPTABLE TYPE> 

<ADAPTABLE FIELD FIXER> ::= <STAR FIXER> 

\<STARRY SUBRANGE F1XER> 
\<LENGTH FIXER> 
\<SPAN FIXERS 

<ADAPTABLE FIELDS : := 

<FIELD SELECTORS : t <ALIGNMENTs] <ADAPTABLE TYPES 

<ADmPTABLE HEAP IDENTIFIERS ::= <IDENTIFIER> 

<ADAPTABLE HEAPS ::= <ADAPTABLE HEAP IDENTIFIERS 

<ADAPIABLE POINTER TO ARRAYS ::= <ADAPTABLE POINTERS 

<ADaPTaBLE POINTER TO HEAPS ::= <ADAPTABLE POINTER> 



SWL EfNF (ALPHABETICAL) 



H-l 



20 <ADAPTABLE POINTER TO SEQUENCE> : != <ADAPTABLE POINTER> 

21 <ADAPTABLE POINTER TO STACK*: := <ADAPTABLE POINTER* 

22 <AOAPTABLE POINTER TO STRING* ::= <ADAPTABLE POINTER> 

23 <ADAPTABLE POINTER* : := -C t READ 3 ] ^ADAPTABLE TYPE> 

24 <ADAPTABLE RECORD SPEC* :: = 

RECORD KFIXED FIELDS** 3 <ADAPTABLE FIELD* RECEND 

25 <ADAPTABLE RECORD TYPE IDENTIFIER* S : = <IDENT IF IER* 

26 <ADAPTABLE RECORO> ::= 

t<PACKING>]<ADAPTABLE RECORD TYPE IDENTIFIER* 
\[<PACKING*3<ADAPTABLE RECORD SPEO 

27 <ADAPTABLE SEQUENCE IDENTIFIER* : := IDENTIFIER* 

28 <ADAPTABLE SEQUENCE* l %~ <ADAPTABLE SEQUENCE IDENTIFIER* 

29 <ADAPTABLE STACK IDENTIFIER* ?:= <IDENTIFIER> 

30 <ADAPTABLE STACK> : ;= ^ADAPTABLE STACK IDENTIFIER> 

\ STACK [*.J OF <TYPE> 

31 <ADAPTABLE STORAGE TYPE* ::= <ADAPTABLE STACK* 

\<ADAPTABLE SEQUENCE> 
\<ADAPTABLE HEAP> 
, \<ADAPTABLE STRING IDENTIFIER* 

32 <ADAPTABLt STRING IDENTIFIER* : := <IDENTIFIER> 

33 <ADAPTABLE TYPE> ::= <ADAPTABLE AGGREGATE TYPE* 

\<ADAPTABLE STORAGE TYPE> 

34 <ADDING OPERATOR* : := + \ - A OR \ XOR \ UOR 

35 <AGGREGATE TYPE> ::= <STRING TYPE* 

\<ARRAY TYPE> 
\<RECORD TYPE> 

36 <ALIGNMENT> ::= ALIGNED 

37 <ALLOCATE STATEMENT> ::= 

ALLOCATE ALLOCATION DESIGNATOR* I IN <HEAP VARIABLE*! 

38 ALLOCATION DESIGNATOR> : := 

<POINTER VARIABLE* 
\<ADAPTABLE POINTER VARIABLE> : [ADAPTABLE FIELD FIXER> 

[»<ADAPTABLE FIELD FIXER>33 
\<POINTER TO BOUND VARIANT RECORD VARIABLE* : 

[<TAG FIELD FlXER> t» <TAG FIELD FIXER>33 



SWL BNF (ALPHABETICAL) 

H-2 



.39 <ALPHAdET> ::= <LETTER> 

\<DIGIT> 
\<SP£CIAL MARK> 
\<BLANKS> 
\<UNUSED MARK> 

40 ALTERNATIVE PARTS> ::= IF <EXPRESSION> THEN <STATEMENT LIST> 

CORIF <EXPRESSION> THEN <STATEMENT LIST>J 

41 <ANY INDEX> : : = <INDEX> \ <STARRED INDEX> 

0,2 <ARRAY EAPRESSION> : := <EXPRESSION> 

\<INDEFINITE VALUE CONSTkUCTOR> 

43 <ARRAY SPEO ::= ARRAY [<INDICES>J OF <C0MP0NtiMT TYPE> 

44 <ARRAY TYPE I0ENTIFIER> : := <IDENTIFIER> 

45 <ARRAY TYPE> ::= !<PACKING> ]<ARRAY TYPE 1DENTIFIER> 

\[<PACKING>]<ARRAY SPEO 

46 <ARRAY VARIABLE> ::= <\/ARIABLE> 

47 <ASCII CHARACTER> : := <ALPHABET>\<UNPR1NT ABLE> 

4b ASSIGNMENT STATEMENT> ll= <VARIABLE> := <EAPRESSION> 

\<FUNCTI0N IDENTIFIER> := <EXPRESSION> 
\<SUCCESSOR ASSIGNMENT "CFo .10.1.2". 
\<PRE0ECESS0R ASSIGNMENT 

49 <ATTRIBUTE> ::= <ACCESS ATTRIBUTE> 

\<ST0RAGE ATTRIBUTE> 
\<SC0PE ATTRIBUTE> 

50 <ATTRIBUTES> ::= t <ATTRI8UTE>[ »<ATTRIBUTE> ] J 

51 <BASE DESIG(MATOR> ::= (<RADIX>) 

52 <BASE TYPE> : := <SCALAR TYPE> 

53 <BASIC C0NSTANT> ::= <SCALAR C0NSTANT> 

\<C0MPILE TIME VARIAbLE> "CF. SECTION 12.1" 
\<REAL C0NSTANT> 
\<P0INTER C0NSTANT> 

54 <BASIC TYPE> ::= <SCALAR TYPE> 

\<REAL TYPE> 
\<P0INTER TYPE> 

55 <B£GIN STATEMENT> :;= 

BEGIN DECLARATION LI STXSTATEMENT LIST> ENO 

56 <BLANKS> H = 

57 <BOOLEAN CONSTANT IDENT IFIER> : := <IDENTIFIER> 



SWL BNF (ALPHABETICAL) 

H-3 



SaH <bOULtAN CONSTANTS ::= FALSE\TRUE\<BOOLEAN CONSTANT IDENTIFIED 

59 <bOOLEAN TYPE IDENTIFIED : := <IDENTIFIER> 

60 <BGOLEAN TYPE> ::= BOOLEAN 

\<BOOLEAN TYPE IDENTIFIER> 

fa! <BOUND VARIANT POINTER> ::= -I C READ ] KBOUND VARIANT RECORD TYPE> 

62 <BOUND VARIANT RECORD TYPE> ::= 

[<PACKING>1 <BOUND VARIANT RECORD TYPE IDENTIFIER> 
\[<PACMNG>] BOUND <VARIANT RECORD SPEO 
\L<PACKIN6>] BOUND <VARIANT RECORD TYPE IDENTIF1ER> 

63 <CASE PART> ::= CASE <TAG FIELD SPEO OF <VARIATI0NS> CASEND 

64 <CASE STATEMENT> ::= CASE <SELECTOR> OF <CASES> 

[ELSE <STATEM£NT LIST>3 CASEND 

6b <CASES> ::= <A CASE>[;<A CASE>] 

66 <CELL TYPE> ::= CELL 

67 <CHARACTER CONSTANT IDENTIFIER> ::= <IDENTIFIER> 

6« <CHARACTER CONSTANT> : := • <ALPHABET>» 

\<CHARACTER CONSTANT IDENT1FIER> 
NSCHAR (<INTEGER>) 

69 <ChARACTER TYPE IDENTIFIER> :: = <IDENTIFIER> 

70 <CHARACTER TYPE> ::= CHAR\<CHARACTER TYPE IDENTIFIER> 

71 <COMMt(MTARY STRING> : := "KCOMMENT CHARACTERS" 

72 <COMPlLATION UNIT> ::= <MODULE DECLARATION> M CF. SECTION 

73 <COMP'ONENT TYPE> :?= <TYPE> 

74 <CONFORMITY> ::= 

<TYPE IDENTIFIER> <TYPE TEST OPERATOR> <UNION VARIABLE> 
\<POINTER VARIABLE> <POINTER TYPE TEST OPERATOR> 

<UNION VARIABLE> 
\<VARIABLE> <VALUE TYPE TEST OPERATOR> <UNION VARIABLE> 

75 <CONSTANT DECLARATION> ::= 

CONST KCONSTANT SPEO [» <CONSTANT SPEOJJ 

76 <CONSTANT IDENTIFIER LIST> ::= <IDENTIFIER LIST> 

77 <CONSTANT SPEO : : = 

<CONSTANT IDENTIFIER LIST> = <C0NSTANT EXP.RESSION> 
\ <EMPTY> 

78 <CONSTANT> ::= <BASIC CONSTANT>\<STRING C0NSTANT> 



SWL BNF (ALPHABETICAL) 

H-4 



79 CONSTRUCTOR ID> ::= <SET TYPE IDENTIFIED 

\<ARRAY TYPE IDENTIFIER> 
\<RECORD TYPE IDENTIFIED 

80 <CONTROL STATEMENT> ! := <PROCEDURE CALL STATEMEi\|T> 

\<CREATE STATEMENT>\<DESTROY STATEMENT> 
\<RESUME STATEMENT>\<CYCLE STATEMENT> 
\<EXIT STATEMENT>\<RETUKN STATEMENT> 
\<60T0 STATEMENT>\<EMPTY STATEMENT> 

81 <C0NTR0L TYPE> ::= <LABEL TYPE> 

\<PR0CEDURE TYPE> 
\<COPROCESS TYPE> 

8^ <C0NTROL VARIABLE> :!= <VARIABLE> 

83 <C0PR0C REFERENCE> ::= <P0INTER TO COPROC>- 

H4 <CUPRUCESS TYPE> ::= COPROC 

85 <CRAMMED ARRAY> !!= 

ARRAY [<CRAMMED INDICES>3 OF <CRAMMED ELEMENT> 

86 <CRAMMED ELEMENT> : : = 

[<MALIGNMENT>] <BOOLEAN TYPE> 

\ [<MAi_IGNMENT>j <INTEGER T YPE> [<WIDTH> J 

\ [<MALIGNMENT>] <INTEGER SUBRANGE TYP£> [ <W IDTH> ] 
\ <CRAMMED TYPE> 

87 <CRAMMED FIELD> : != <I0ENTIFIER LIST> : <CRAMMED ELEMEnT> 



88 



<CftAMMED 1NDEX> :i= <FIXEO SCALAR TYPE> 



89 <CRAMMED IND1CES> '• != <CRAMMED INDEX> t»<CRAMMED INDEX>] 

90 <CRAMMED REC0RD> ::= 

KECORD <CRAMMED FIELD> [ * <CRAMMED FIELD>3 RECEND 

91 <CRAMMEO STRUCTURE> : := <CRAMMED ARRAY>\<CRAMMED HECORD> 

92 <CRAMMED TYPE> ::= [ <MALIGNMENT> ] CRAMMED <CRAMMED STRUCTURE> 

93 <CREATE STATEMENT> $:= 

CREATE (<POINTER TO COPROC>9 <PROCEDURE CALL STATEMENT>) 

94 <CYCLE STATEMENT> ::= CYCLE [<LABEL>H WHEN <EXPRESSION> J 

95 <DATA TYPE> : := <TYPE> 

96 DECLARATION LIST> :!= [<DECLARATION> ;J 



SWL BNF (ALPHABETICAL) 



H-5 



97 DECLARATION* s: = <TYPE DECLARATION* 

\ <VARIABLE DECLARATION* 
\ <SEGMENT DECLARATION* 
\ <MODULE DECLARATION* 
\ <PROCEDURE DECLARATION 
\ <LABEL DECLARATION* 
\ <MICRO DECLARATION* 
\ <EMPTY> 

9H DECREMENT* : := EXPRESSION* 

99 <DEFINITE FILE VARIABLE CONSTRUCTOR* ::= 
$<FILE TYPE* KFILE EXPRESSION*] 

100 <DEFINITE VALUE CONSTRUCTOR* ::= 

S<CONSTRUCTOR ID* C<VALUE ELEMENTS*] 

101 <OESTROY STATEMENT* ::= 

DESTROY UPOINTER TO COPROC* C»<POINTER TO COPROO]) 

102 <OI6IT> ::= 0\1\2\3\4\5\6\7.\8\9 

103 <UIRECT POINTER TYPE* * 5= <POINTER TO TYPE* 

\<FORMAL POINTER* 

104 <EMPTY STATEMENT* : := 

105 <ENCODING> ii= 'ASCII' \ 'EBCDIC \ • SIX-TWELVE-ASCI I • \ ... 

106 <EXIT STATEMENT> ::=■ EXIT KLABEL OR PROC IDENTIFIER*] 

[WHEN EXPRESSION*] 

107 EXPONENTIATING OPERATOR* ::= ** 

108 <EXPRESSION> ::= <SIMPLE EXPRESSION* 

\<SIMPLE EXPRESSIONXRELATIONAL OPERATOR> 
<SIMPLE EXPRESSION* 

109 <FACTOR> s:= <C0NF0RMITY*\<VARIABLE>\<C0NSTANT* 

\<DEFINITE VALUE CONSTRUCTOR*\-<VARIABLE*\-<LABEL* 
\-<PROCEDURE IDENTIFIER>\<FUNCTION DESIGNATOR* 
\ (EXPRESSION*) \<NOT OPERATOR><FACTOR> 



110 <FIELD REFERENCE* 

HI EIELD SELECTOR* ! 

112 <FIELD SELECTORS* 

113 <FILE ATTRIBUTE> ! 



:= <RECORD VARIABLE*. <FIELD SELECTOR> 

= <IDENTIFIER> 

:= <FIELD SELECTOR* t»<FIELD SELECTOR*] 

= <OLD NOR NEW> . . 

\ <MODE* 

\ <ENCODING> 

\ <POSITION> 



114 <FILE ATTRIBUTES* J S= <FILE ATTRIBUTE* [»<FILE ATTRIBUTE*] 
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lb <FII_E SPEO ::= <ACTUAL FILE NAME> 19<FILE ATTRIBUTES>] 

lb <FILE TYPE> ?:= LEGIBLE \ PRINT \ BINARY \ DIRECT 

17 <FILE VARIABLE INITIALIZATION> ::= 

:= <FILE EXPRESSION> 
\ := INDEFINITE FILE VARIABLE CONSTRUCTOR> 

IB <FILE VARIABLE SPEO ::= <VARIABLE IDENTIF1ERS> : 

[<SCOPE OR STORAGE ATTRIBUTES>J 
<FILE TYPE> "CF. 4. 6" 
KFILE VARIABLE INI T I ALIZATI0N> J "CF. b.7" 

19 <FINAL VALUE> : : = <EXPRESSION> 

20 <FIRST ChAR> ::= <P0SITIVE INTEGER EXPRESSION> 

21 <FIXED FIELD> ::= <FIELD SELECTORS> : [<ALI6NMENT>] <FIxED TYPE> 

22 <FIaED FIELDS> ::= <FIXED FIELD> [ * <FIXED FIELD>] 

23 <FIXED OR VARIABLE BOUND TYPE> ::= 

<BASIC TYPE> V STRUCTURED TYPE> \ <ST0RAGE TYPE> 

24 <FIxED RECORD TYPE> : := <INVARIANT RECORD TYPE> 

\<VARIANT RECORD TYPE> 

25 <FOLLOWER> :: = <LETTER>\<DIGlT>\«.\#\$\l<"i 

26 <FOR LIST> s: = 

<INIT1AL VALUE> TO <FINAL VALUE>IBY <INCREMENT>1 
\<INITIAL VALUE> DOwNTO <FINAL VALUE>LBY <DECREMENT>3 

27 <FOR STATEMENT> : := FOR <CONTROL VARIABLE> := <FOR LIST> DO 

<STATEMENT LIST> FOREND 

28 <FORMAL PARAM LIST> ::= IDENTIFIER LIST> 

29 <FGRMAL PARAM LIST> ::= IDENTIFIER LIST> 

30 <FURMAL POINTER> ;:= <ADAPTABLE POINTER> 

\<P0INTER TO CONTROL> 
\<BOUND VARIANT POINTER> 

31 <FORMAL TYPE> : := <ADAPTA8LE TYPE> "CF. 4.b" 

\<CONTROL TYPE> "CF. 4.6" 

\<BOUND VARIANT RECORD TYPE> "CF. 4.7" 

32 <FREE STATEMENT> ::= 

FREE <ALLOCATION DESIGNATOR>[ IN <HEAP VARIABLES 

33 <FUNCTION DESIGNATOR> : := 

<PROCEDURE REFERENCEX<ACTUAL PARAMETER> 
[s<ACTUAL PARAMETERS) 

\<PROCEDURE REFERENCEX ) 
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134 <FUNCT10N IDENTIFIED ::= <PROCEDURE IDENTIFIED 

135 <GOT0 STATEMENTS ;:= GOTO [EXIT] <LABEL REFEKENCE> 

136 <HEAP TYPE> ::= HEAP (<SPACE>) "CF. 4.4.4'* 

137 <HEAP VARIABLE> : := <VARIABLE> 

138 " <hEX DIG1T> ::= A\B\C\D\E\F~ 

\<DIGIT> 

139 IDENTIFIER LIST> : : = <IDENTIFIER>t »<IDENTIFIER>] 

140 <IDENTIFIER> ::= <LETTER>[ <FOLLOWER>] 

141 <IF STATEMENT> ::= 

ALTERNATIVE PARTS> IFEND 
\<ALTERNATIVE PARTS> ELSE <STATEMENT LIST> IFEND 

142 <INCREMENT> ::= <EXPRESSION> 

143 <INDEFINITE FILE VARIABLE CONSTRUCTOR> :: = KFILE SPEO J 

144 INDEFINITE VALUE C0NSTRUCT0R> ::= [<VALUE ELEMENTS>1 

14b <INDEX> ::= <SCALAR TYPE> 

\<SCALAR EXPRESSION> .. <SCALAR EXPRESSION> 

146 <INDICES> : := <INDEX>[»<INDEX>I 

147 <1NIT1AL VALUE> : := <EXPRESSION> 

14B <INITIALIZATI0N> ::= := <EXPRESSION> 

\ S= INDEFINITE VALUE C0NSTRUCT0R> 

149 <INTEGER CONSTANT IDENTIFIER> ::= <IDENTIFIER> 

150 <INTEGER C0NSTANT> ::= <InTEGER>\<INTEGER CONSTANT IDENTIFIER> 

151 •• <INTEGER TYPE IDENTIFIER> : := <IDENTIFIER> 

15? <INTEGER TYPE> ::= INTEGER\< INTEGER TYPE IDENTIFIER> 

153" <INTEGER> i := <DIGIT>[<DIGIT>] 

\<DIGIT>[<HEX DIGIT>] <BASE DESIGNATOR> 

154 <INVARIANT RECORD SPEO : := RECORD <FIXED FIELDS> RECEND 

155 <INVARIANT RECORD TYPE> : := 

[<PACKING>] <INVARIANT RECORD TYPE IOENTIFIER> 
\[<PACKING>3 <INVARIANT RECORD SPEO 

156 <LAB£L DECLARATION> ; := LABEL <LABEL>[» <LABEL>] 
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157' <LABEL OR PROC IDENT1FIER> ::= <LABEL>\<PROCEOURE IDENTIFIER> 

ibh <LABEL REFERENCE> ::= <LABEL> \ <POINTER TO l_ABEL>- 

169 <LAnEL TYPE> ::= LABEL 

loO <LABEL> :s= <IDENTIFIER> 

161 <LENGTH FIXER> ::= <SCALAR EXPRESSION^ 

lb? <LEM6TH> ::= <POSITIVE INTEGER EXPRESSION 

ltj3 <LETTER> ::= A\B\C\D\E\F\G\H\I \J\K\L\M\N\0\P\U\R\S\T\UW\w\X\ V \Z 

104 <L00P STATEMENT> ::= LOOP <STATEMENT LIST> LOOPEND 

16b <LOwER> ::= <CONSTANT SCALAR EXPRESSION> 

166 <MALIGNMENT> :: = MALIGNED (<OFFSET>[ » <BASE> J ) 

167 <MEmBERS> ::= <TYPE LIST> 

168 <MOOE> ::= READErWRITE] \ WRITE! »READJ 

169 . <MOOULE BODY> ::= <DECLARATION LIST> 

170 <MO0OlE DECLARATION> ::= 

MODOLE KMODULE IDENTIFIERS [< (PRONGS) >3 i 

<MODULE BODY> 

MODEND KMODULE IDENTIFIERS 

171 <M0DULE IDENTIFIERS' :: = <IDENTIFIER> 

1/2 MULTIPLYING OPERATORS ::= * \ / \ MOD \ AND \ CAND 

173 <NEXT STATEMENT> ::= 

NEXT ALLOCATION DESIGNATOR> IN <SEQUENCE VARIABLE> 

174 <NOT OPERATOR> i '>= NOT 

175 <NTH> ::= <INTEGER EXPRESSION> 
17b <ObJECT TYPE> ::= <TYPE> 

177 <OLD OR NEh> ::= OLD \ NEW 

17« <ORDINAL CONSTANT IDENTIFIER LIST> ::= 

<ORDINAL CONSTANT IDENTIFIER>»<ORDINAL CONSTANT IDENT1FIER> 
[♦<ORDINAL CONSTANT IDENTIFIER:*] 

179 <ORDINAL CONSTANT IDENTIFIER> : := <IDENTIFIER> 

180 <ORDINAL CONSTANT IDENTIFIER> ! := <IDENTIFIER> 

161 <ORuINAL CONSTANT> ::= <ORDINAL CONSTANT IDENTIFIER> 
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182 <0R01NA|_ TYPE IDENTIFIER> : := < IDENTIFIER> 

1b3 <URDINAL TYPE> ::= (<ORDINAL CONSTANT IDENTIFIER LIST>) 

\<ORDINAL TYPE IDENTIFIER> 

18* <PACKING ATTRIBUTES> ::= PACKED \ UNPACKED 

ldb <PACKING> ::= <PACKING ATTRIBUTES> 



186 <PARAM SEGMENT> : 

187 <PAHAMETER LIST> 
18b <PARENTAL TYPE> : 



= <REFERENCE PARAMS>\<VALUE PARAMS> 

:= (<PARAM SEGMENT>[;<PARAM SEGMENT>J> 

= <STORAGE TYPE> 
\<AGGREGATE TYPE> 



189 <POINFER CONFORMITY CASE STATEMENT> : := CASE :-: <UNION VARIABLE> 

OF <POINTER CONFORMITY CASES>£ELSE <STATEMENT LIST>J CASEND 

190 <P01NTER CONFORMITY CASES> : := 

<A POINTER CONFORMITY CASE>t;<A POINTER CONFORMITY CASE>3 

191 <POINTER CONSTANT 1UENTIFIER> : := <IDENTIFIER> 

192 <P01NTER CONSTANT> ::= NIL 

193 <P01NTER REFERENCE> ::= <POINTER VARIABLE> 

\<FUNCTION DESIGNATOR> 

1S4 <POINTER TO CONTROL> ::= -<CONTROL TYPE> 

195 <POInTER TO COPROO : := <FORMAL P0INTER> 

196 <PGINTER TO COPROO ::= <VARIABLE> 

197 <POINTER TO F ILE> 5 := -<FILE TYPE> 

198 <P01NTER TO LABEL> :: = <FORMAL POINTER> 

199 <POINTER TO PROCEDURE> ::= <FORMAL POINTER> 

200 <P01NTER TO TYPE> ::= -[ I READ J 3 <FIXED OR VARIABLE BOUND TYPE> 

\<P0INTER TO FILE> 

201 <POINTER TYPE SPECIFIER> ::= <P0INTER VARIABLE> 

£02 <P0INTER TYPE TEST OPERATOR> ::= :-: 

203 <POINTER TYPE> ::= <DIRECT POINTER TYPE> 

\<RELATIVE POINTER TYPE> 

204- <P0INTER VARIABLE> ::= <VARIABLE> 

<f05 <POP STATEMENT> : := POP <POINTER VARIABLE> ON <STACK VARIABLE> 

206 <P0S1TI0N> ::= FIRST \ ASIS \ LAST ( 

SWL BNF (ALPHABETICAL) 

H-10 



£07 <POwER> ::= <FACTOR> \ <POwER> <EXP0NENT I AT ION OPERATOR> <FACTOR> 

£Oti <HREL)ECESSOR ASSIGNMENT^ ::= <SCALAR VARIABLE> :- <NTH> 

£09 <PkOC ATTR1BUTE> ::= XOCL \ REPDEP \ <St(iMENT IDENTIFIED 

£10 <PKOC ATTRIBUTES> : := <PROC ATTRI BUTE> t <PROC ATTRIBUTE^] 



£11 <PROC bODY> 
£1£ <PROC END> : 
£13 <PROC SPEO 



eLiU 


dlH 


ddO 


dd\ 


ddd 


dc3 


d'dh 


d'db 


ddb 


ddl 


diti 


dd<4 



:= DECLARATION LIST> <STATEMENT LIST> 

= PROCEND [<PROCEDURE IDENTIFIED 3 

:= <PROCEDURE IDENTIFIER> <PR0C TYPE SPEO 



\ <PROCEDURE IDENTIFIER> <PROCEDURE TYPE> 

214 <PH0C TYPE ATTRIBUTES> ::= 

<NULL CONSTRUCT (FOR EXPANSION PURPOSES)> 

dlb <PHOC TYPE SPEO :: = 

[t<PROC TYPE ATTRIBUT£S>] ]t<PARAMETER LIST> ] [ <KETUkN TYPE>J 

*lb <PK0C£DURE CALL STATEMENT> ::= 

<PROCEDURE REFERENCED <ACTUAL PARAMETER LlST> 

217 <PH0CE0URE UECLARATION> ::= 

PKOC [ XREF ) <PR0C SPEO 
\ PR0CLt<PR0C ATTR16UTES>]]<PR0C SPEO»<PROC BODYXPROC END> 

PROCEDURE IDENTIFIER> !'•= <IDENTIFIER> 

<PROCtL)URE REFERENCE> ::= <PROCEDURE IDENTIFIER> 

\<P0INTER TO PRUCEDUKE>- 

<PROCEDURE TYPE IDENTIFIER> : := <IDENTIFIER> 

<PROCEDURE TYPE> •*: = <PROCEDURE TYPE IUENTIFIER> 

\PROC <PR0C TYPE SPEO 

<PR0NoS> ::= <IDENTIFIER LIST> 

<PUSH STATEMENT> :! = PUSH <P0INTER VARIABLE> ON <STACK VAHIA8LE> 

\ PUSH <ALL0CATI0N DESIGNATOR> 

<RAD1X> : := d \ 4 \ B \ 10 \ lfa 

<real constant ioentifier> ::= <id£ntifier> 

<real c0nstant> ::= <r€al number>\<real constant identifier> 

<real number> :;= <unscaled number> 

\<scaled number> 

<real type identifiers ::= <identifier> 

<real type> ::= real\<real type identifier> 
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230 <RECORD EXPRESSION> ::= <EXPRESSION> 

\<INDEFINITE VALUE CONSTRUCTOR> 

,231 <RECORD TYPE> ::= <FIXED RECORD TYPE> , 

\<VARIABLE BOUND RECORD TYPE> 

232 <RECORD VARIA8LE> : := <VARIABLE> 

233 <REF TYPE> ::= <SWL TYPE> 
23* <REF TYPE> ::= <SWL TYPE> 

235 <REFEKENCE PARAMS> ;:= 

REF <FORMAL PARAM LIST> : [[ READ ]]<REF TYPE> 

236 RELATIONAL OPERATOR> : := < \ <= \ > \ >= \ = \ /= \ IN 

c37 <RELATIVE POINTER TYPE> ::= 

REL[ (<PARENTAL TYPE>> ]-<OBJECT TYPE> 

238 <REP SPEO ::= REP <POSITIVE INTEGER EXPRESSION> OF 

239 <REP TYPE> ::= <CELL TYPE> 

\<CRAMMED TYPE> 

240 <REPEAT STATEMENT> ;:= REPEAT <STATEMENT LIST> UNTIL <EXPRESSI0N> 

241 <RESET STATEMENT> i := 

RESET <SEQUENCE VARIABLES TO <POINTER VARIABLES 
\ RESET <STACK VARIABLE> [TO <POINTER VARIABLES 
\ RESET <HEAP VARIABLE> 

242 <RLSUHt STATEMENT> ::= RESUME KCOPROC REFERENCE>) 

243 <RETURN STATEMENT> ::= RETURN [WHEN <EXPRESSI0N>1 

£44 <RETURN TYPE> ::= <BASIC TYPE> 

24b <SCALAR C0NSTANT> : := <ORDINAL C0NSTANT> 

\<B00LEAN CONSTANT> 
\<INTEGER C0NSTANT> 
\<CHARACTER C0NSTANT> 

2*6 <SCALAR TYPE> 5: = <INTEGER TYPE> 

\<CHARACTER TYPE> 
\<0RDINAL TYPE> 
\<800LEAN TYPE> 
\<SUBRANGE TYPE> 

247 <SCALED NUMBER> ::= <UNSCALED NUMBER> E [<SIGN>1<DIGIT>[ <DIGI T>] 

2*8 <SCOPE ATTRIBUTE> : := XDCL \ XREF \ EXTERNAL 

249 <SCOP£ OR STORAGE ATTRIBUTE> ::= 

<SCOPE ATTRIBUTE> [»<STORAGE ATTRIBUTE>] ( 
\ <STORAGE ATTRIBUTE> [*<SCOPE ATTRIBUTE>] 
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250 <SEGMENT DECLARATION> ::= SEGMENT <SE6MENTS>9 <SEGMENTS> 

k-e>l <SEGMENT IDENTIFIER> ::= <IDENTIFIER> 

db2 <SEGMENT IDENTIFIERS> ::= <SEGMENT IDENTIFIER> 

[9<SEGMENT IDENTIFIERS 

db3 <SEGMENTS> :: = <SEGMENT IDENTIF IERS> : [ KACCESS AT TRlHUTES> ] ] 

db* <SELECTION SPEO ::= <C0NSTANT SCALAR EXPRESSIUN> 

[••<C0NSTANT SCALAR EXPRESbION> J 

ebb <SELECTION VAI_UE> : := <C0NSTANT SCALAR EXPRESS10N> 

( .. <C0MSTANT SCALAR EXPRESSION] 

dbb SELECTION VALUES> ::= 

<SELECTI0N VALUE> [* <SELECTIOiM VALUE>J 

db7 <SELECTION VALUES> ::= <SELECTI0N VALUE> I 9 <S£LECTI0N VALUE>3 

dbb <SELECT0R> ::= <EXPRESSI0N> 

259 <SEQ0ENCE TYPE> ::= SEU (<SPACE>) 

dbi) <SE0GENCE VARIABLE> : := <VAPIABLE> 

261 <SET TYPE IDENTIFIER> ::= <IDENTIFIER> 

262 <SE7 TYPE> ::= SET OF <8ASE TYPE> 

\<SET TYPE IDENTIFIER> 

263 <SIGN> ::= + \ - 

264 <SIMPLE EXPRESSION :!= <TERM> \ <SIGN><TERM> 

\<SIMPLE EXPRESS10N> 

<ADDING 0PERAT0R><TEHM> 

265 <SPACE> ::= <SPAN>[ 9<SPAN> J 

<;66 <SPAN F1XER> ::= t<SPAN> [9 <SPAN> J] 

267 <SPAN> ::= [REP <P0SITIVE INTEGER EXPRESSI0N> UFI 
<TYPE IDENTIFIERS 

26ti <SPECIAL mark> ::= +\-\*\/\ .\ ; \ :\"\ • 

\#\3>\«A(P>\?\<\>\=\<\> 

269 <STACK SIZE> ::= <INTEGER EXPRESSI0N> 

d7Q <STACK TYPE> ::= STACK KSTACK SIZE>I OF <TYPE> 

dll <STACK VARIABLE> ::= <VAHIABLE> 
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did <STAK FIXER> :!= <SCALAH EXPRESSION .. <SCALAR EXPRESSION> 

273 <STAH> ::= * \ * : <SCALAR TYPE> 

274 <STARRED INDEX> ::= <STAR> \ <STARRED SUbRANGE> 

dfb <STARRED LIST> ::= 

[<INDEX>»1 <STARRED INDEX> t* <ANY INDEX>J 

alt, <STARRED SUBRAN6E> : := tt •• <S'CALAR EXPRESSION 

\<SCALAR EXPRESSION> .. * 

ell <STARRY SUBRANGE FlXER> ::= <SCALAR EXPRESSION 

278 <STATEMENT LlST> :: = <STA TEMENT>[ ;<STATEMENT> J 

279 <STATEMEI\lT> ': := <UNL.ABELED STATEMENT>\<LABEL> : <STATEMENT> 

^80 <STORAGE MANAGEMENT STA.TEMENT> ::= <PUSH STATEMENT> 

\<POP STATEMENT> 
\<NEXT STATEMENT> 
\<RESET STATEMENT> 
\<ALLOCATE STATEME»MT> 
\<FREE STATEMENT> 

281 <STORAGE TYPE> ::= <STACK TYPE> 

\<SEOUENCE TYPE> 
\<HEAP TYPE> 

dZd <STRING CONSTANT IDENTIFIER> ::= <IDENTIFIER> 

283 <STRING CONSTANTS ::= <STRING TERM> [CAT <STRING TERM>] 

284 <STRING TERM> : := <CHARACTER CONSTANT> 

\<STRING CONSTANT IDENTIFIER> 
V<AI_PHABET> <ALPHABET> KALPHABET>] • 

285 <STRING TYPE IOENTIFIER> ::= <IDENTIFIER> 

28b <STRIN6 TYPE> : := STRING (<LENGTH>) OF <CHARACTER*»TYPE> 

\<STRING TYPE IDENTIFIERS 

dVl <STRING VARIABLE> : := <VARIABLE> 

288 <STRUCTURED STATEMENT> ::= <BEGIN STATEMENT> 

\<IF STATEMENT>\<LOOP STATEMENT> 
\<WHILE STATEMENT>\<REPEAT STATEMENT> 
\<FOR STATEMENT>\<CASE STATEMENT 
\<VALUE CONFORMITY CASE STATEMENT> 
\<POINTER CONFORMITY CASE STATEMENT> 
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i>«S» STRUCTURED TYPE> ::= <SET TYPE> 

\<UNI0N TYPE> 
\<AG6REGATE TYPE> 

290 SUBRANGE TYPE 1DENTIFIER> ::= <IDENTIFIER> 

291 SUBRANGE TYPE> ::= <SU6RANGE TYPE IDENTIFIER> 

\<LOWER>..<UPPER> 

^V2 <SUBSCRIPT> ::= <SCALAR EXPRESSION> 

293 SUBSCRIPTED REFERENCE> ::= <ARRAY VARIABLE> ISUBSCRIPTS> J 

294 <SU8SCRIPTS> ::= <SUBSCRIPT>[ 9<SUBSCR IPT> 3 

29b SUBSTRING LENGTH> ::= <P0SITIVE INTEGER EXPkESSION> 

29fa SUBSTRING KEFERENCE> • := STRING VAR I ABLE> (<SUBSTR ING SPEO) 

297 <SUBSTRING SPEC> ::= <FIRST CHAR> [ 9 SUbSTRlNG LENGTOJ 

2V8 <SUCCESSOR ASSIGNMENT ::= <SCALAR VARIABLE> :+ <NTH> 

299 <SwL TYPE> ::= <0ATA TYPE> 

\<F0RMAL TYPE> 

300 <TAG FIELD FIXER> ::= SCALAR EXPRESSION> 

301 <TAG FIELD SELECT0R> ;:= <IDENTIFIER> 

302 <TAG FIELD SPEC> ::= 

<TAG FIELD SELECT0R> : [<ALIGNMENT> 1 <TAG FIELD TYPE> 

303 <TAG FIELD TYPE> ::= <SCALAR TYPE> 

304 <TERM> ::= <POWER>\<TERMXMULTIPLYlNG UPERAT0R><P0wER> 
30b <TYPE DECLARATION> ::= TYPE KTYPE SPEOC* <TYPE SPEOJ ] 

306 <TYPE IDENTIFIER LIST> ::= <IDENTIFIER LIST> 

307 <TYPE IDENTIFI£R> : J= <IDENTIFIER> 

308 <TYPE LIST> : ;= <TYPE> £» <TYPE>] 

309 <TYPE SPEO ::= <TYPE IDENTIFIER LIST> = SwL TYPE> \ <EMPTY> 

310 <TYPE TEST 0PERAT0R> ::= :: 

Jll <TYPE> ::= <FIXED OR VARIABLE BOUND TYPE> \ <FILE TYPE> 
312 <UNI0N TYPE> ::= 1<PACKIN6>] UNION (<MEMBERS>) 
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313 <UNION V£RIABLE> ::= <VARIABLE> 

314 <Ul\iION VARIA8LE> ::= <VARIABLE> 

31b <UNLABELED STATEMENT> : := ASSIGNMENT STATEMENT > 

\<STRUCTUREO STATEMENT >[ <LABEL> J 
\<CONTROL STATEMENT> 
\<STORAGE MANAGEMENT STATEMENT> 
\<INPUT-OUTPUT STATEMENT> 

316 <UNSCALED NUMBER> : := <DIG1 T>[<DIGIT> J »<UIGIT>L <DIGIT>] 

317 <UNUSED MARK> ::= <»\ \[\]\\\%\LW 

318 <UPPER> ::= <CONSTANT SCALAR EXPRESSION> 

319 <VAL TYPE> ::= 

<TYPE> \ <ADAPTABLE TYPE> \ <BOUND VARIANT RECORD TYPE> 

320 <VAL TYPE> : := 

<TYPE> \ <ADAPTABLE TYPE> \ <BOUND VARIANT RECORD TYPE> 

321 <VALUE CONFORMITY CASE STATEMENT> ::= 

CASE !=: <UNION VARIABLE> OF <VALUE CONFORMITY CASES> 
[ELSE <STATEMENT LIST> 1 CASEND 

322 <VALOE CONFORMITY CASES> ::= 

<A VALOE CONFORMITY CASE> [{ <A VALUE CONFORMITY CASE> 1 

323 <VALUE ELEMENT>'::= [<REP SPEOKEXPRESSION> 

\[<REP SPEC>]<INDEFINITE VALUE CONSTRUCTOR> 
\[<REP SPEC>J * 

324 <VALUE ELEMENTS> ::= <VALUE ELEMENT>t *<VALUE ELEMENT>J 

325 <VALUE PARAMS> ::= 

VAL <FORMAL PARAM LIST> : tC READ 1KVAL TYPE> 

326 <VALUE PARAMS> : := 

VAL <FORMAL PARAM LIST> : IT READ ]J<VAL TYPE> 

327 <VALUE PARAMS> ::= 

VAL <FORMAL PARAM LIST> : CI READ ]3<VAL TYPE> 

32B <VALUE TYPE SPECIFIER> ::= <VARIABLE> 

329 <VALUE TYPE TEST OPERATOR> ::= :=: 

330 <VARIABLE BOUND F1ELD> ::= 

<FIELD SELECTOR> : t <ALIGNMENT> 3 <VARI ABLE BOUND TYPE> 

331 ^VARIABLE BOUND RECORD SPEO ::= 

RECORDT<FIXED F IELDS>» 3<VARIABLE bOUND FIELD>RECEND ( 
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332 <VARIABLE BOUND RECORD TYPE> ::= 

[<PACKING>]<VARlABLE BOUND RECORD TYPE 1DENTIFIER> 
\t<PACKIN6>]<VARIAt)LE BOUND KECORD SPEO 

333 <VARIABLE DECLARATION> :: = 

VAR [VARIABLE SPEO C» <VARIABLE SPEOJJ 
\ VAR L<FILE VARIABLE SPEC>[»<FILE VARIAdLE SPEOJ] 

334 <VARIABLE IDENTIFIER> ::= < IDEiMTIFIER> 

335 <VARIAULE IDENTIFIERS> ::= 

<VARIABLE IDENTIFIER> INVARIABLE IDENTIFIERS 

336 <vARlAriLE REFERENCE> ::= <VARIABLE IDENTIFIED 

\<POINTER REFERENCE;— 
\<SUBSTRING REFERENCt> 
\<SUBSCRIPTED REfERENCt> 
\<FIELD REFERENCE> 

337 <VAk1ABLE SPEC> :: = 

<TYPE>[ INITIALIZATION] 
\<EMPTY> 

338 <VARlAfcSLE> :: = <VARIABLE REFERENCE> 

339 <VARIANT RECORD SPEC> : := 

KECORD KFIXED FIELDS>»] <CASE PAh<T> RECENO 

340 <VARIANT RECORD SPEC> ::= 

RECORD KFIXED FIELDS>9l <CASE PaRT> RECEND 

341 <VAKIANT RECORD TYPE> H= 

[<PACKING>] <VARIANT RECORD TYPE IDENTIFIER> 
\KPACKING>] <VAR1ANT RECORD SPEO 

342 <VARIANT> ::= <FIXED FIELDS> 

\[<FIXED FIELDS>»I <CASE PART> 

343 <VARIATION> : := =<SELECTION VALUES>= <VARIANT> 

344 <VARIATIONS> J := <VARIATI0N> [» <VARIATION>J 

345 <whILE STATEMENT> ::= 

WHILE <EXPRESSION> DO <STATEMENT LIST> wHILEND 

346 <WlDTti> ::= <INTE6ER C0NSTANT> 
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